From nobody Tue Aug 18 10:46:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8858F3A08EB for ; Tue, 18 Aug 2020 10:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDBd3dk1HGXs for ; Tue, 18 Aug 2020 10:46:00 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D013A08E4 for ; Tue, 18 Aug 2020 10:45:59 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id f26so22380474ljc.8 for ; Tue, 18 Aug 2020 10:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SN5jjz9n57li62TcWigvNXYFoVLEQhOfpamB844mu/M=; b=afeZpfDM0mFcdNGN2ibHA3AScqizGkjomfOoyF8lgxS07k5iSxsSI+dlo1JXIZUjpZ ozIOP15y5d94lapc/VZMGSl7Kn3iXVQxa8zNa4rjn+BKeEjgUWF4OW58QTPZA4yl3KDZ 2vDeIEqt3sIw7SrIunZkkpcDVg01yczKnVL+udEFft1BLRfY7sHycfZ4j9FoPEpnY2aO 1F/+6wy0OKfZDQnOEyaTeuZ1leP1J0sDurt3EdaCgVmfsFyI7CUNy5Cp2L/vKwCgZw+M QEMbvW/w7ctbYa2m78llcdPZP/im2T64QeOOU78ceMjl28Nci4C1lrXYlxkP4QN+0/NW 9N7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SN5jjz9n57li62TcWigvNXYFoVLEQhOfpamB844mu/M=; b=e2ysnN/+kiaF3/azax+6wnB1SuvLjX4ZCLlaytaToU4sGR3NVliQQ7DYp9hyts0yVX 5n3p65BTwLCjpvBcEmHeHiMcjKK2TwH2KpwWrrqUwrVPMw8qbTwY/SBx7TTghxb5LcPh WGnedyvG6UQ+VkvmUIP58hxVRv62oRB/Iiqxx8P9/4LRScEoWjadGg85T6mFtStXIRQz DiRtdrbbTcMXTSDgpftQ3g3srWdbagpxoHX3RMGGEstatNn3M19FPqrdOJt1yiEqcB8Q IDCcwRT5Zg4cGhL6tXALkW/ObIyERmvS0WqSg4GJ9vtDOGkdY3TC1tOOHzSR6UIa7M8f 6VBA== X-Gm-Message-State: AOAM531jQ6UmizYVYGwc6N8WbkbZZRPsXnxYi/tOXlAjw4gBx2/EndfX tRiCjBFXYuFrd4F7j/3ojT3CodbmyAPiAroSLfWdYgWvRJ8= X-Google-Smtp-Source: ABdhPJwEYzrvjwqGPViTMfV+Dfv2tyljHCPDc81hGS4o9daSna88C0YslmoDsfUThAMvpgXZ7nB3ycvP6FRVaDROVjw= X-Received: by 2002:a2e:2283:: with SMTP id i125mr10119558lji.142.1597772757444; Tue, 18 Aug 2020 10:45:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 18 Aug 2020 10:45:21 -0700 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a3c67105ad2a752b" Archived-At: Subject: Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introduction X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 17:46:05 -0000 --000000000000a3c67105ad2a752b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis Thanks for taking the time to review the latest draft While *your* cases may require certain conditions, other use cases have other conditions. For example, existing OAuth 2 flows do NOT have the client query the RS first. Per the charter, supporting OAuth 2 use cases is in scope. =E1=90=A7 On Tue, Aug 18, 2020 at 10:29 AM Denis wrote: > Hi Dick, > > I have taken a look at the specification and there are good news but > unfortunately also bad news. > > The good news: There is a Privacy considerations section (section 11) > > The bad news: There is the title of that section, but no text in it. > > The good news: The first exchange is now between the client and the RS: > > (1) The GC may query the RS to determine what the RS requires from a GS > for resource access. > > The bad news: The text is using a "may" and continues with: "This step is > not in scope for this document". > > This first flow is fundamental and if the client has never contacted the > RS before, that step shall be performed. > Hence, the use of the word "may" is inappropriate. In addition, using the > singular "for a GS" is also inappropriate since a RS > may trust more than one GS. > > Please take a look at the uses cases I have posted today called: > "Enterprise servers and Internet servers use cases" > The document is available at : > https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Inter= net-servers-use-cases > > This post attempts to explain why this first flow is the most important. > IMHO, it should be within the scope. > > BTW, I don't like the wording "Grant Client" since it is ambiguous as it > does not make any difference between what I call > a "User Client" and an "Enterprise Client". > > The text then uses the following sentence which is inappropriate for > various reasons: > > The Grant Client may be interacting with a human end-user (User), > > A user client *must *be interacting with a human end-user (User). The > User must interact using, what I call, a "User Agent". > > and the Grant Client may need to get authorization to release the Grant > from the User, > > Further down, a grant is defined as: "the user identity claims and/or > resource access the GS has granted to the Client". > > Such a definition is inappropriate since a grant is first of all an acces= s > token issued by an AS that contains attributes and/or > capabilities that allow to perform some method(s) on a data object. > > Before an access token is issued for a User, a User Consent, as well as > some choices, made by the User shall be obtained. > This does not apply when an access token is issued for a client (i.e. a > piece of software). The vocabulary that is being used > does not allow to make these major differences. > > or from the owner of the resources at the Resource Server, the Resource > Owner (RO). > > No authorization is needed by the owner of the resource. A Resource > Controller (RC) is a piece of software that applies a set of rules > to grant or to deny access to a data object using some method. No human > interaction from a human being sitting next to the RS is ever needed. > > The uses cases I posted today contain a more detailed model that is able > to support both capabilities and ABAC (Attribute-based Access Control). > > Denis > > Hello > > I just pushed an updated version of XAuth: > > https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html > > Highlights: > > - renamed Client -> Grant Client > - Introduced Client Owner, Grant Server Owner as new entities > - renamed Authorizations -> Access > - An Access contains an array of RAR objects now > - Reworked diagram an intro to focus on Grant, and separate protocol > roles from human interactions. > > New introduction included below for your convenience > > /Dick > > - > > 1. > > Introduction > > > *EDITOR NOTE* > > *This document captures a number of concepts that may be adopted by the > proposed GNAP working group. Please refer to this document as:* > > *XAuth* > > *The use of GNAP in this document is not intended to be a declaration of > it being endorsed by the GNAP working group.* > > This document describes the core Grant Negotiation and Authorization > Protocol (GNAP). The protocol supports the widely deployed use cases > supported by OAuth 2.0 [RFC6749 > ] & > [RFC6750 > ], > OpenID Connect [OIDC > ] - an > extension of OAuth 2.0, as well as other extensions. Related documents > include: GNAP - Advanced Features [GNAP_Advanced > > ] and JOSE Authentication [JOSE_Authentication > > ] that describes the JOSE mechanisms for client authentication. > > The technology landscape has changed since OAuth 2.0 was initially > drafted. More interactions happen on mobile devices than PCs. Modern > browsers now directly support asymetric cryptographic functions. Standard= s > have emerged for signing and encrypting tokens with rich payloads (JOSE) > that are widely deployed. > > GNAP simplifies the overall architectural model, takes advantage of > today's technology landscape, provides support for all the widely deploye= d > use cases, offers numerous extension points, and addresses many of the > security issues in OAuth 2.0 by passing parameters securely between parti= es > rather than via a browser redirection. > > While GNAP is not backwards compatible with OAuth 2.0, it strives to > minimize the migration effort. > > The suggested pronunciation of GNAP is "guh-nap". > 1.1. > The > Grant > > > The Grant is at the center of the protocol between a client and a server. > A Grant Client requests a Grant from a Grant Server. The Grant Client and > Grant Server negotiate the Grant. The Grant Server acquires authorization > to grant the Grant to the Grant Client. The Grant Server then returns the > Grant to the Grant Client. > > The Grant Request may contain information about the User, the Grant > Client, the interaction modes supported by the Grant Client, the requeste= d > identity claims, and the requested resource access. Extensions may define > additional information to be included in the Grant Request. > 1.2. > Protocol > Roles > > > There are three roles in GNAP: the Grant Client (GC), the Grant Server > (GS), and the Resource Server (RS). Below is how the roles interact: > > +--------+ +------------+ > | Grant | - - - - - - -(1)- - - - - - ->| Resource | > | Client | | Server | > | (GC) | +---------------+ | (RS) | > | |--(2)->| Grant | | | > | |<-(3)->| Server |- (6) -| | > | |<-(4)--| (GS) | | | > | | +---------------+ | | > | | | | > | |--------------(5)------------->| | > +--------+ +------------+ > > (1) The GC may query the RS to determine what the RS requires from a GS > for resource access. This step is not in scope for this document. > > (2) The GC makes a Grant request to the GS (Create Grant Section 3.2 > ). > How the GC authenticates to the GS is not in scope for this document. One > mechanism is [JOSE_Authentication > > ]. > > (3) The GC and GS may negotiate the Grant. > > (4) The GS returns a Grant to the GC (Grant Response Section 4.1 > > ). > > (5) The GC accesses resources at the RS (RS Access Section 6 > ). > > (6) The RS evaluates access granted by the GS to determine access granted > to the GC. This step is not in scope for this document. > 1.3. > Human > Interactions > > > The Grant Client may be interacting with a human end-user (User), and the > Grant Client may need to get authorization to release the Grant from the > User, or from the owner of the resources at the Resource Server, the > Resource Owner (RO) > > Below is when the human interactions may occur in the protocol: > > +--------+ +------------+ > | User | | Resource | > | | | Owner (RO) | > +--------+ +------------+ > + + + > + + + > (A) (B) (C) > + + + > + + + > +--------+ + + +------------+ > | Grant | - - -+- - - -(1)- - - -+- - ->| Resource | > | Client | + + | Server | > | (GC) | +---------------+ | (RS) | > | |--(2)->| Grant | | | > | |<-(3)->| Server |- (6) -| | > | |<-(4)--| (GS) | | | > | | +---------------+ | | > | | | | > | |--------------(5)------------->| | > +--------+ +------------+ > > Legend > + + + indicates an interaction with a human > ----- indicates an interaction between protocol roles > > Steps (1) - (6) are the same as Section 1.2 > . > The addition of the human interactions (A) - (C) are *bolded* below. > > *(A) The User is interacting with a GC, and the GC needs resource access > and/or identity claims (a Grant)* > > (1) The GC may query the RS to determine what the RS requires from a GS > for resource access > > (2) The GC makes a Grant request to the GS > > (3) The GC and GS may negotiate the Grant > > *(B) The GS may interact with the User for grant authorization* > > *(C) The GS may interact with the RO for grant authorization* > > (4) The GS returns a Grant to the GC > > (5) The GC accesses resources at the RS > > (6) The RS evaluates access granted by the GS to determine access granted > to the GC > > Alternatively, the Resource Owner could be a legal entity that has a > software component that the Grant Server interacts with for Grant > authorization. This interaction is not in scope of this document. > 1.4. > Trust > Model > > > In addition to the User and the Resource Owner, there are three other > entities that are part of the trust model: > > - *Client Owner* (CO) - the legal entity that owns the Grant Client. > - *Grant Server Owner* (GSO) - the legal entity that owns the Grant > Server. > - *Claims Issuer* (Issuer) - a legal entity that issues identity > claims about the User. The Grant Server Owner may be an Issuer, and th= e > Resource Owner may be an Issuer. > > These three entities do not interact in the protocol, but are trusted by > the User and the Resource Owner: > > +------------+ +--------------+----------+ > | User | >> (A) >> | Grant Server | | > | | | Owner (GSO) | | > +------------+ > +--------------+ | > V / ^ | Claims | > (B) (C) (E) | Issuer | > V / ^ | (Issuer) | > +------------+ > +--------------+ | > | Client | | Resource | | > | Owner (CO) | >> (D) >> | Owner (RO) | | > +------------+ +--------------+----------+ > > (A) User trusts the GSO to acquire authorization before making a grant to > the CO > > (B) User trusts the CO to act in the User's best interest with the Grant > the GSO grants to the CO > > (C) CO trusts claims issued by the GSO > > (D) CO trusts claims issued by the RO > > (E) RO trusts the GSO to manage access to the RO resources > 1.5. > > Terminology > > > *Roles* > > - > > *Grant Client* (GC) > - may want access to resources at a Resource Server > - may be interacting with a User and want identity claims about the > User > - requests the Grant Service to grant resource access and identity > claims > - > > *Grant Server* (GS) > - accepts Grant requests from the GC for resource access and identity > claims > - negotiates the interaction mode with the GC if interaction is > required with the User > - acquires authorization from the User before granting identity > claims to the GC > - acquires authorization from the RO before granting resource > access to the GC > - grants resource access and identity claims to the GC > - > > *Resource Server* (RS) > - has resources that the GC may want to access > - expresses what the GC must obtain from the GS for access through > documentation or an API. This is not in scope for this document > - verifies the GS granted access to the GC, when the GS makes > resource access requests > > *Humans* > > - > > *User* > - the person interacting with the Grant Client. > - has delegated access to identity claims about themselves to the > Grant Server. > - may authenticate at the GS.. > - > > *Resource Owner* (RO) > - the legal entity that owns resources at the Resource Server (RS). > - has delegated resource access management to the GS. > - may be the User, or may be a different entity that the GS > interacts with independently. > > *Reused Terms* > > - *access token* - an access token as defined in [RFC6749 > = ] Section > 1.4.. An GC uses an access token for resource access at a RS. > - *Claim* - a Claim as defined in [OIDC > ] S= ection > 5. Claims are issued by a Claims Issuer. > - *Client ID* - a GS unique identifier for a Registered Client as > defined in [RFC6749 > = ] Section > 2.2. > - *ID Token* - an ID Token as defined in [OIDC > ] S= ection > 2. ID Tokens are issued by the GS. The GC uses an ID Token to authenti= cate > the User. > - *NumericDate* - a NumericDate as defined in [RFC7519 > = ] Section > 2. > - *authN* - short for authentication. > - *authZ* - short for authorization. > > *New Terms* > > - *GS URI* - the endpoint at the GS the GC calls to create a Grant, > and is the unique identifier for the GS. > - *Registered Client* - a GC that has registered with the GS and has a > Client ID to identify itself, and can prove it possesses a key that is > linked to the Client ID. The GS may have different policies for what > different Registered Clients can request. A Registered Client MAY be > interacting with a User. > - *Dynamic Client* - a GC that has not been previously registered with > the GS, and each instance will generate it's own asymetric key pair so= it > can prove it is the same instance of the GC on subsequent requests.. T= he GS > MAY return a Dynamic Client a Client Handle for the Dynamic Client to > identify itself in subsequent requests. A single-page application with= no > active server component is an example of a Dynamic Client. > - *Client Handle* - a unique identifier at the GS for a Dynamic Client > for the Dynamic Client to refer to itself in subsequent requests. > - *Interaction* - how the GC directs the User to interact with the GS. > This document defines the interaction modes: "redirect", "indirect", a= nd > "user_code" in Section 5 > > . > - *Grant* - the user identity claims and/or resource access the GS has > granted to the Client. The GS MAY invalidate a Grant at any time. > - *Grant URI* - the URI that represents the Grant. The Grant URI MUST > start with the GS URI. > - *Access* - the access granted by the RO to the GC and contains an > access token. The GS may invalidate an Access at any time. > - *Access URI* - the URI that represents the Access the GC was granted > by the RO. The Access URI MUST start with the GS URI.. The Access URI = is > used to refresh an access token. > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a3c67105ad2a752b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis

Thanks for taking the time to = review the latest=C2=A0draft

While *your* cases ma= y require certain conditions, other use cases have other conditions.
<= div>
For example, existing OAuth 2 flows do NOT have the clie= nt query the RS first. Per the charter, supporting OAuth 2 use cases is in = scope.


3D""=E1=90=A7
On= Tue, Aug 18, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hi Dick,

I have taken a look at the specification and there are good news but unfortunately also bad news.

The good news: There is a Privacy considerations section (section 11)

The bad news: There is the title of that section, but no text in it.

The good news: The first exchange is now between the client and the RS:
(1) The GC may query the RS to determine what the RS requires from a GS for resource access.
The bad news: The text is using a "may" and continues with: "This step= is not in scope for this document".

This first flow is fundamental and if the client has never contacted the RS before, that step shall be performed.
Hence, the use of the word "may" is inappropriate. In add= ition, using the singular "for a GS" is also inappropriate since= a RS
may trust more than one GS.

Please take a look at the uses cases I have posted today called: "Enterprise servers and Internet servers use cases"

This post attempts to explain why this first flow is the most important. IMHO, it should be within the scope.

BTW, I don't like the wording "Grant Client" since it is ambiguous as it do= es not make any difference between what I call
a "User Client" and an "Enterprise Client".

The text then uses the following sentence which is inappropriate for various reasons:
The Grant Client may be interacting with a human end-user (User),
A user client must be interacting with a human end-user (User). The User must interact using, what I call, a "User Agent".
and the Grant Client may need to get authorization to release the Grant from the User,
Further down, a grant is defined as: "the user identity claims and/or resource access the GS has granted to the Client".

Such a definition is inappropriate since a grant is first of all an access token issued by an AS that contains attributes and/or
capabilities that allow to perform some method(s) on a data object.

Before an access token is issued for a User, a User Consent, as well as some choices, made by the User shall be obtained.
This does not apply when an access token is issued for a client (i.e. a piece of software). The vocabulary that is being used
does not allow to make these major differences.
or from the owner of the resources at the Resource Server, the Resource Owner (RO).
No authorization is needed by the owner of the resource. A Resource Controller (RC) is a piece of software that applies a set of rules
to grant or to deny access to a data object using some method. No human interaction from a human being sitting next to the RS is ever needed.

The uses cases I posted today contain a more detailed model that is able to support both capabilities and ABAC (Attribute-based Access Control).

Denis

=20
Hello

I just pushed an updated version of XAuth:


Highlights:
  • renamed Client -> Grant Client
  • Introduced Client Owner, Grant Server Owner as new entities
  • renamed=C2=A0Authorizations -> Access
  • An Access contains=C2=A0an array of RAR objects now
  • Reworked diagram an intro to focus on Grant, and separate protocol roles from human interactions.
New introduction included below for your convenience

/Dick

1.=C2=A0Introduction

EDITOR NOTE

This document captures a number of concepts that may be adopted by the proposed GNAP working group. Please refer to this document as:

XAuth

The use of GNAP in this document is not intended to be a declaration of it being endorsed by the GNAP working group.

This document describes the core Grant Negotiation and Authorization Protocol (GNAP). The protocol supports the widely deployed use cases supported by OAuth 2.0=C2=A0[RFC6749]=C2= =A0&=C2=A0[RFC6750], OpenID Connect=C2=A0[OIDC]=C2=A0-= an extension of OAuth 2.0, as well as other extensions. Related documents include: GNAP - Advanced Features=C2=A0[GNAP_Advanc= ed]=C2=A0and JOSE Authentication=C2=A0[JO= SE_Authentication]=C2=A0that describes the JOSE mechanisms for client authentication.

The technology landscape has changed since OAuth 2.0 was initially drafted. More interactions happen on mobile devices than PCs. Modern browsers now directly support asymetric cryptographic functions. Standards have emerged for signing and encrypting tokens with rich payloads (JOSE) that are widely deployed.

GNAP simplifies the overall architectural model, takes advantage of today's technology landscape, provides support for all the widely deployed use cases, offers numerous extension points, and addresses many of the security issues in OAuth 2.0 by passing parameters securely between parties rather than via a browser redirection.

While GNAP is not backwards compatible with OAuth 2.0, it strives to minimize the migration effort.

The suggested pronunciation of GNAP is "guh-nap"= ;.

1.1.=C2=A0The Grant

The Grant is at the center of the protocol between a client and a server. A Grant Client requests a Grant from a Grant Server. The Grant Client and Grant Server negotiate the Grant. The Grant Server acquires authorization to grant the Grant to the Grant Client. The Grant Server then returns the Grant to the Grant Client.

The Grant Request may contain information about the User, the Grant Client, the interaction modes supported by the Grant Client, the requested identity claims, and the requested resource access. Extensions may define additional information to be included in the Grant Request.

1.2.=C2=A0Protocol Roles

There are three roles in GNAP: the Grant Client (GC), the Grant Server (GS), and the Resource Server (RS). Below is how the roles interact:

+----= ----+ +------------+ | Grant | - - - - - - -(1)- - - - - - ->| Resource | | Client | | Server | | (GC) | +---------------+ | (RS) | | |--(2)->| Grant | | | | |<-(3)->| Server |- (6) -| | | |<-(4)--| (GS) | | | | | +---------------+ | | | | | | | |--------------(5)------------->| | +--------+ +------------+

(1) The GC may query the RS to determine what the RS requires from a GS for resource access. This step is not in scope for this document.

(2) The GC makes a Grant request to the GS (Create Grant=C2=A0Section 3.2). How the GC authenticates to the GS is not in scope for this document. One mechanism is=C2=A0[JOSE_Authentication].

(3) The GC and GS may negotiate the Grant.

(4) The GS returns a Grant to the GC (Grant Response=C2=A0<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#Gran= tResponse" style=3D"text-decoration-line:none;color:rgb(34,34,238)" target= =3D"_blank">Section 4.1).

(5) The GC accesses resources at the RS (RS Access=C2=A0Section 6).

(6) The RS evaluates access granted by the GS to determine access granted to the GC. This step is not in scope for this document.

<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.3" style=3D"text-decoration-line:none;padding-right:0.5em;color:rgb(3= 4,34,34)" target=3D"_blank">1.3.=C2=A0Human Intera= ctions

The Grant Client may be interacting with a human end-user (User), and the Grant Client may need to get authorization to release the Grant from the User, or from the owner of the resources at the Resource Server, the Resource Owner (RO)

Below is when the human interactions may occur in the protocol:

+----= ----+ +------------+ | User | | Resource | | | | Owner (RO) | +--------+ +------------+ + + + + + + (A) (B) (C) + + + + + + +--------+ + + +------------+ | Grant | - - -+- - - -(1)- - - -+- - ->| Resource | | Client | + + | Server | | (GC) | +---------------+ | (RS) | | |--(2)->| Grant | | | | |<-(3)->| Server |- (6) -| | | |<-(4)--| (GS) | | | | | +---------------+ | | | | | | | |--------------(5)------------->| | +--------+ +------------+ Legend + + + indicates an interaction with a human ----- indicates an interaction between protocol roles

Steps (1) - (6) are the same as=C2=A0Section 1.2<= /a>. The addition of the human interactions (A) - (C) are=C2=A0bolded=C2=A0below.

(A) The User is interacting with a GC, and the GC needs resource access and/or identity claims (a Grant)

(1) The GC may query the RS to determine what the RS requires from a GS for resource access

(2) The GC makes a Grant request to the GS

(3) The GC and GS may negotiate the Grant

(B) The GS may interact with the User for grant authorization

(C) The GS may interact with the RO for grant authorization

(4) The GS returns a Grant to the GC

(5) The GC accesses resources at the RS

(6) The RS evaluates access granted by the GS to determine access granted to the GC

Alternatively, the Resource Owner could be a legal entity that has a software component that the Grant Server interacts with for Grant authorization. This interaction is not in scope of this document.

1.4.=C2=A0Trust Model

In addition to the User and the Resource Owner, there are three other entities that are part of the trust model:

  • Client Owner=C2= =A0(CO) - the legal entity that owns the Grant Client.
  • Grant Server Owner=C2=A0(GSO) - the legal entity that owns the Grant Server.
  • Claims Issuer=C2= =A0(Issuer) - a legal entity that issues identity claims about the User. The Grant Server Owner may be an Issuer, and the Resource Owner may be an Issuer.

These three entities do not interact in the protocol, but are trusted by the User and the Resource Owner:

+------= ------+ +--------------+----------+ | User | >> (A) >> | Grant Server | | | | | Owner (GSO) | | +------------+ > +--------------+ | V / ^ | Claims | (B) (C) (E) | Issuer | V / ^ | (Issuer) | +------------+ > +--------------+ | | Client | | Resource | | | Owner (CO) | >> (D) >> | Owner (RO) | | +------------+ +--------------+----------+

(A) User trusts the GSO to acquire authorization before making a grant to the CO

(B) User trusts the CO to act in the User's best interes= t with the Grant the GSO grants to the CO

(C) CO trusts claims issued by the GSO

(D) CO trusts claims issued by the RO

(E) RO trusts the GSO to manage access to the RO resources

1.5.=C2=A0Terminology

Roles

  • Grant Client=C2=A0(GC)

    • may want access to resources at a Resource Server
    • may be interacting with a User and want identity claims about the User
    • requests the Grant Service to grant resource access and identity claims

  • Grant Server=C2=A0(GS)

    • accepts Grant requests from the GC for resource access and identity claims
    • negotiates the interaction mode with the GC if interaction is required with the User
    • acquires authorization from the User before granting identity claims to the GC
    • acquires authorization from the RO before granting resource access to the GC
    • grants resource access and identity claims to the GC

  • Resource Server=C2=A0(RS)

    • has resources that the GC may want to access
    • expresses what the GC must obtain from the GS for access through documentation or an API. This is not in scope for this document
    • verifies the GS granted access to the GC, when the GS makes resource access requests

Humans

  • User=

    • the person interacting with the Grant Client.
    • has delegated access to identity claims about themselves to the Grant Server.
    • may authenticate at the GS..

  • Resource Owner=C2=A0(RO)

    • the legal entity that owns resources at the Resource Server (RS).
    • has delegated resource access management to the GS.
    • may be the User, or may be a different entity that the GS interacts with independently.

Reused Terms

  • access token=C2= =A0- an access token as defined in=C2=A0[RFC6= 749]=C2=A0Section 1.4.. An GC uses an access token for resource access at a RS.
  • Claim=C2=A0- a C= laim as defined in=C2=A0[OIDC]=C2= =A0Section 5. Claims are issued by a Claims Issuer.
  • Client ID=C2=A0-= a GS unique identifier for a Registered Client as defined in=C2=A0[RFC6749]= =C2=A0Section 2.2.
  • ID Token=C2=A0- = an ID Token as defined in=C2=A0[OIDC]=C2=A0Section 2. ID Tokens are issued by the GS. The GC uses an ID Token to authenticate the User.
  • NumericDate=C2= =A0- a NumericDate as defined in=C2=A0[RFC75= 19]=C2=A0Section 2.
  • authN=C2=A0- sho= rt for authentication.
  • authZ=C2=A0- sho= rt for authorization.

New Terms

  • GS URI=C2=A0- th= e endpoint at the GS the GC calls to create a Grant, and is the unique identifier for the GS.
  • Registered Client=C2=A0- a GC that has registered with the GS and has a Client ID to identify itself, and can prove it possesses a key that is linked to the Client ID. The GS may have different policies for what different Registered Clients can request. A Registered Client MAY be interacting with a User.
  • Dynamic Client= =C2=A0- a GC that has not been previously registered with the GS, and each instance will generate it's own asymetric key pair so it can prove i= t is the same instance of the GC on subsequent requests.. The GS MAY return a Dynamic Client a Client Handle for the Dynamic Client to identify itself in subsequent requests. A single-page application with no active server component is an example of a Dynamic Client.
  • Client Handle=C2= =A0- a unique identifier at the GS for a Dynamic Client for the Dynamic Client to refer to itself in subsequent requests.
  • Interaction=C2= =A0- how the GC directs the User to interact with the GS. This document defines the interaction modes: "redirect", "indirect"= , and "user_code" in=C2=A0Section 5.
  • Grant=C2=A0- the= user identity claims and/or resource access the GS has granted to the Client. The GS MAY invalidate a Grant at any time.
  • Grant URI=C2=A0-= the URI that represents the Grant. The Grant URI MUST start with the GS URI.
  • Access=C2=A0- th= e access granted by the RO to the GC and contains an access token. The GS may invalidate an Access at any time.
  • Access URI=C2=A0= - the URI that represents the Access the GC was granted by the RO. The Access URI MUST start with the GS URI.. The Access URI is used to refresh an access token.




--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a3c67105ad2a752b--