From nobody Mon Aug 17 04:28:09 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 DCEF83A14D0 for ; Mon, 17 Aug 2020 04:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=adorsys.de 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 9VuFICSmcPuL for ; Mon, 17 Aug 2020 04:28:03 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 824913A14CC for ; Mon, 17 Aug 2020 04:28:02 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id c19so13009358wmd.1 for ; Mon, 17 Aug 2020 04:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cGEVxEbr46InVUr6r3Tk6XkkbCg6j5D2M8NanpYEYcc=; b=PYyQl9hF2h7tgsUdQm1vUK/pMK2+iv5bB/XBd97orbXwr47StQUQqBbfLs181OU6Kl iiwN8WZZ0BwzPfg9ugusKFxyW69OEf3wVh5N5CHHeP+wOy6kGWdWug4ivJSWzvfjtQI6 6lu4cDZASFsoK/bbkVuoQF8IgCmu/C09nccCg= 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=cGEVxEbr46InVUr6r3Tk6XkkbCg6j5D2M8NanpYEYcc=; b=MBX8enYId1L4vEA0kuYp7xCkDGdl23wIG4UlHNZbjL5z5slU2ZpELPR/tLqx7mOIPv iX3Vm0tiQzv4w5rXptFvFGO2AAMT3J//3iszKdEElurbif5WD7orQSd7UBa4uuF1N2zN yQZ/neosvbygMuQXRjolDdOSuhg/hRuZhg2MgtzR2r1gCcUOj2k/+wSbFlhwHNXMHRGW /+enfc3TDCfz7c6DknVHMiBGO4yAXBx6meYCcSmG6tfJJDH8TukCkZurc8WZL/j8JbRI TDN5cBu7EzAzEmwExtMtWYCbwkSf/sF2j+keWxkb9f1usbkJC+hrADCW2DvIjw72D5yM e0rA== X-Gm-Message-State: AOAM531lKi7A1ZKKgQ2Zn9ZsRr+dBnxEGn+bP8dkB0PWqfS6jhJRmq0Z W4gTKIoFA3Po3WTNmS89ROCA1EZ0+iE3Dgzxx54VWg== X-Google-Smtp-Source: ABdhPJwuacSotfxR3goMxef2/zwsgiiSTdbvDxnIzAxhYT3q7xCLozZVaDH4XOD3GMFCkJ9hajqh8OdXw4AyTwm2vIQ= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr13938749wmj.8.1597663680519; Mon, 17 Aug 2020 04:28:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Mon, 17 Aug 2020 07:27:49 -0400 Message-ID: To: Fabien Imbault Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000025f65b05ad111028" 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: Mon, 17 Aug 2020 11:28:07 -0000 --00000000000025f65b05ad111028 Content-Type: text/plain; charset="UTF-8" Hello Fabian, inline On Mon, Aug 17, 2020 at 6:56 AM Fabien Imbault wrote: > Hi Francis, > > I like that alt2 introduces the additional discussions we had previously > (on privacy and other topics) but I think this schema is too prescriptive. > This is why I pushed them into Alt-2. In the most common use case at sight (oAuth2), GS, RC-AS, RP-AS are roles that might be represented by the same entity. This means the oAuth2 instantiated model might look very simple. > > Depending on the situation, one may either require the GS to provide the > front-channel, or decide to separate it. > Yes. This is why exposing RC-AS in the diagram makes that case visible. In those situations, [GS]=[RC-AS]=[RP-AS]=GS resulting in the original model of Dick. > Why mandate that interaction B shall always occur through the GC? If I' a > GC, I could just as well decide that it's enough to just separate the > front-channel from the GS, without handling it myself. > Having GS +++(B)+++> RP is the oAuth2 model again. THis is what Dick has in the original diagram. There are some cases where GS might need to gain knowledge of some claims about RP, but do not need to know their identity. E.g.: age(RP) > 18. In those cases [GS] --(3)-->[GC]++(B)++>[RP] makes sense. And in some cases RP-AS resides on RP's device (SSI). And we find ourself with: [GS] --(3)-->[GC]-->(B0)-->[RP-AS]++(B1)++>[RP] > Why mandate that interaction C shall always occur through a GS? (I'm sure > Denis will not want this, for instance). > This is not a mandate, but an abstract model. In SSI/DID most of the time, RP-RC will also reside on a user device. Are we sure we need to formally separate B and C? This goes beyond previous > discussions of separating the front and back channels, and I don't really > see the advantage (maybe there is: which use cases would be impossible to > do otherwise?). > We have a situation where RP =!= RC. And each of them have their own AS. > So overall, I think Alt2 over-complexifies the situation. We need to > remain flexible. > Why not simply have an (optional) way of separating these flows from the > GS? > With GNAP, we are at an abstraction level-0, like referred to in my former post. At level-1 we can address concrete protocols like oAuth, OIDC, [SSI/DiD/VC] and the diagram will look simple. > For instance, an (optional) Interact Server (IS) could provide support for > a decoupled front-channel: > - it does not change the interaction between a GC and a GS. It does change > the trust model though, depending on which options are chosen. In practice, > the GC may specify which IS it wants to use (it can be his own, for > instance). In case nothing is specified, the GS decides. > - the IS is able to handle the front-channel for idclaims and consent, and > return back to the GS what access tokens are required. > - notice that although the IS is focused on front-channel interaction, > there are cases where the consent needs to be based on policies instead of > a direct human interaction (typically when end-user is not the RC, and > therefore the end-user is not the one that is asked for consent / then of > course, if the RC logs in, he would be able to manage his consent > policies). > What you mention here is why I display RP-AS and RC-AS! > So there's really no obligation that B occurs through the GC and C occurs > through the GS. It depends on where your front-channel is located (GC, GS, > third-party). > Yes. I agree with you. How can we make this visible in a diagram? This I think makes it a very flexible model, while enabling what we're > after. > Yes. /Francis > > Fabien > > > On Mon, Aug 17, 2020 at 4:38 AM Francis Pouatcha 40adorsys.de@dmarc.ietf.org <40adorsys.de@dmarc..ietf.org>> wrote: > >> Hello Dick, >> >> Thanks for pointing this out. This is the new diagram where ++++ >> refers to what Endpoint/Human interaction and ----> refers to interaction >> among services. >> >> +-------------+ +----------------+ >> | Requesting | | Resource | >> | Party (RP) | | Controller (RC)| >> +-------------+ +----------------+ >> + + + >> + + + >> (A) (B1) (C1) >> + + + >> +. + + >> + +--------+ +--------+ >> + | RP-AS | | RC-AS | >> + +--->| | +-->| | >> + | +--------+ | +--------+ >> + | | >> + (B0) | >> + | (C0) >> +--------+ | +------------+ >> | Grant |--------(1)------|------------>| Resource | >> | Client | | | Server | >> | (GC) | +---------------+ | (RS) | >> | |--(2)->| Grant | | | >> | |<-(3)->| Server |- (6) -| | >> | |<-(4)--| (GS) | | | >> | | +---------------+ | | >> | | | | >> | |--------------(5)------------->| | >> +--------+ +------------+ >> >> >> It is still important to know what is part of the protocol: >> Alt-1: only (1..6). This is what you specified in section 1.2, and I am >> fine with that. >> Alt-2: Alt-1 + (B0, C0). This is a result of the discussion we have been >> having around privacy, GS as big brother, aso.... >> >> P.S.: an authentication [RP]+++(A)+++>[GC] can be assumed, but shall be >> irrelevant for the protocol. [RP]+++(B1)+++>[RP-AS] is important for later >> instantiation of the model. As in many cases, like in oAuth [RP-AS] could >> be the same entity like [GS]. >> >> Best regards. >> /Francis >> >> >> On Sun, Aug 16, 2020 at 7:04 PM Dick Hardt wrote: >> >>> Hi Francis >>> >>> I was intentional in stating 1.3 that it is human interactions. The >>> connection lines are '+ + +' rather than '-----' to indicate that it is a >>> human interaction rather than a protocol between roles. We can't specify >>> how a human interaction works, but we can show when they might occur >>> relative to the rest of the protocol >>> >>> In the abstract diagram in 1.3, I show the interactions between the User >>> and the GC, the User and the GS, and the RO and the GS. These are NOT >>> interactions that can be technically specified. The User and RO are not >>> roles in the protocol, but are entities in the trust model. >>> >>> I debated keeping the interactions abstract and not stating "what" >>> happened in each interaction, but thought that might be confusing at this >>> stage or our discussions. >>> >>> Since it is just an interaction between human and software, we can have >>> the User authenticate to the GC as well as authorize (provide consent), and >>> have no interaction at the GS. We would need to define how to represent the >>> authorization and the consent for the GC to pass to the GS, but the roles >>> and entities stay the same. The trust model does change though. >>> >>> /Dick >>> >>> >>> >>> >>> >>> >>> >>> On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha wrote: >>> >>>> Hello Dick, my feedback below: >>>> >>>> 1.2: Excellent and Focussed >>>> -> The word "Grant Client" looks great for me. >>>> >>>> 1.3: >>>> Title: Human Interaction -> End User Interaction >>>> I would title this "End User" interaction and not "human ...". It is >>>> not about having a human, but a terminating edge of the protocol. An "End >>>> User" can be either human on an IOT device or a car or ... >>>> >>>> Participant: User -> "Requesting Party" >>>> I will still insist on replacing the word "User" with a role name. >>>> Maybe "Requesting Party" as used by UMA. >>>> >>>> Participant: "Resource Controller". In past discussions there was a >>>> consensus on using "Resource Controller" instead. >>>> >>>> (B) I which the GS never interacts with the "Requesting Party" in a >>>> matter of obtaining a grant to a resource (many reasons: privacy, >>>> confidentiality, abstraction, ...). Generally the GS will need information >>>> (claims) about the "Requesting Party" to proceed with the authorisation >>>> decision. In this case, the GS can instruct the GC to obtain those claims. >>>> In some cases, claims on the "Requesting Party" will be obtained from >>>> another "Authorization Server" (AS). The word AS is intentionally chosen >>>> here. In this same login, the path (C0, C1) below will not only return the >>>> RC consent, but might also return some claims on RC. >>>> >>>> ASs provide authentication "of" and consent collection "from" End >>>> Users. End users are in this case the Requesting Party, and the Resource >>>> Controller). >>>> >>>> The result can look like the modified diagram below. With this we can >>>> address some privacy concerns that are being discussed on the list. >>>> >>>> +-------------+ +----------------+ >>>> | Requesting | | Resource | >>>> | Party (RP) | | Controller (RC)| >>>> +-------------+ +----------------+ >>>> + + + >>>> + + + >>>> (A) (B1) (C1) >>>> + + + >>>> +. + + >>>> + +--------+ +--------+ >>>> + | RP-AS | | RC-AS | >>>> + | | | | >>>> + +--------+ +--------+ >>>> + + + >>>> + (B0) + >>>> + + (C0) >>>> +--------+ + + +------------+ >>>> | Grant | - - - -(1)- - - - + - - - - ->| Resource | >>>> | Client | + | Server | >>>> | (GC) | +---------------+ | (RS) | >>>> | |--(2)->| Grant | | | >>>> | |<-(3)->| Server |- (6) -| | >>>> | |<-(4)--| (GS) | | | >>>> | | +---------------+ | | >>>> | | | | >>>> | |--------------(5)------------->| | >>>> +--------+ +------------+ >>>> >>>> (B0, B1) replace (B). Occur inside step (3), GS asks GC to collect the >>>> claims. GC contacts RP-AS to negotiate those claims. But it is important to >>>> mention that those Claims-RP are not the target Grant being negotiated for >>>> the resource access. They are generally used by GS (and later RS) as input >>>> into performing authz decisions. >>>> >>>> (C0, C1) replace (C). They occur after step (3) (Beware of the >>>> difference to Bs that occur inside 3). This separation address the Big >>>> Brother problem we have been discussing in the list. >>>> >>>> Essential is to mention that in an instantiation of this model for >>>> oAuth for example: >>>> - GS, RP-AS and RC-AS might be the same entity. >>>> - RP and RC might refer to the same "End User". >>>> >>>> Off-topic: The splitting of GS and AS was suggested in some discussions >>>> on the mailing list. But we have no mean yet to isolate good inputs for >>>> later reuse. This is why I suggest we compile some inputs into tickets or >>>> wiki pages (like use cases). >>>> >>>> 1.4: >>>> The Trust model introduces what I would rather call the trust >>>> framework. The purpose of the trust framework will be to address topics >>>> mentioned in this section. There is still a lot of discussion needed to >>>> have a structure for this section. >>>> >>>> >>>> 1.5 >>>> I suggest again we replace Human with "End User" and still make them >>>> roles. This is: >>>> Terminology (Are all roles) >>>> -> These roles can be borne by End Users >>>> -> Requesting Party (RP) >>>> -> Resource Controller (RC) >>>> -> These role can be borne by Services >>>> -> GS >>>> -> GC >>>> -> RS >>>> -> RP-AS >>>> -> RC-AS >>>> >>>> I will stop here, as the fundamental agreement on this structure is >>>> necessary for a qualified review of section 2++. >>>> >>>> Best regards >>>> /Francis >>>> >>>> On Sat, Aug 15, 2020 at 7:03 PM Dick Hardt >>>> wrote: >>>> >>>>> 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. 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. >>>>> 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 requested >>>>> 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 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 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 >>>>> >>>>> ] Section 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 >>>>> >>>>> ] Section 2. ID Tokens are issued by the GS. The GC uses an ID >>>>> Token to authenticate 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.. 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* - 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", >>>>> and "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 >>>>> >>>> >>>> >>>> -- >>>> Francis Pouatcha >>>> Co-Founder and Technical Lead >>>> adorsys GmbH & Co. KG >>>> https://adorsys-platform.de/solutions/ >>>> >>> >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead >> adorsys GmbH & Co. KG >> https://adorsys-platform.de/solutions/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --00000000000025f65b05ad111028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Fabian, inline

On Mon, Aug 17, 2020= at 6:56 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2= =A0

I like that alt2 introduces the additional discussio= ns we had previously (on privacy and other topics) but I think this schema = is too prescriptive.
This is why I pushed them= into Alt-2.=C2=A0
In the most common use case at sight (oAuth2),= GS, RC-AS,=C2=A0 RP-AS are roles that might be represented by the same ent= ity. This means the oAuth2 instantiated model might look very simple.
=

=C2=A0

Depending on the s= ituation, one may either require the GS to provide the front-channel, or de= cide to separate it.
Yes. This is why exposing= RC-AS in the diagram makes that case visible. In those situations,=C2=A0[G= S]=3D[RC-AS]=3D[RP-AS]=3DGS resulting=C2=A0 in the original model of Dick.<= /div>
=C2=A0
Why mandate that interaction B shall always occur throug= h the GC? If I' a GC, I could just as well decide that it's enough = to just separate the front-channel from the GS, without handling it myself.=
Having GS +++(B)+++> RP is the oAuth2 mode= l again. THis is what Dick has in the=C2=A0original diagram.

=
There are some cases where GS might need to gain knowledge of so= me claims about RP, but do not need to know their identity. E.g.: age(RP) &= gt; 18.=C2=A0
In those cases [GS] --(3)-->[GC]++(B)++>[RP] = makes sense.

And in some cases RP-AS resides on RP= 's device (SSI). And we find ourself with:
[GS] --(3)-->[G= C]-->(B0)-->[RP-AS]++(B1)++>[RP]
=C2=A0
Why mandat= e that interaction C shall always occur through a GS? (I'm sure Denis w= ill not want this, for instance).
This is not = a mandate, but an abstract model. In SSI/DID most of the time, RP-RC will a= lso reside on a user device.

Are we sure we need to formal= ly separate B and C? This goes beyond previous discussions of separating th= e front and back channels, and I don't really see the advantage (maybe = there is: which use cases would be impossible to do otherwise?).=C2=A0
We have a situation where RP =3D!=3D RC. And each = of them have their own AS.


So overall, I th= ink Alt2 over-complexifies the situation. We need to remain flexible.
=
Why not simply have an (optional) way of separating these flows from t= he GS?=C2=A0
With GNAP, we are at an abstracti= on=C2=A0level-0, like referred=C2=A0to in my former post. At level-1 we can= address concrete protocols like oAuth, OIDC, [SSI/DiD/VC] and the diagram = will look simple.


For instance, an (optiona= l) Interact Server (IS) could provide support for a decoupled front-channel= :=C2=A0
- it does not change the interaction between a GC and a G= S. It does change the trust model though, depending on which options are ch= osen. In practice, the GC may specify which IS it wants to use (it can be h= is own, for instance). In case nothing is specified, the GS decides.=C2=A0<= /div>
- the IS is able to handle the front-channel for idclaims and con= sent, and return back to the GS what access tokens are required.
= - notice that although the IS is focused on front-channel interaction, ther= e are cases where the consent needs to be based on policies instead of a di= rect human interaction (typically when end-user is not the RC, and therefor= e the end-user is not the one that is asked for consent / then of course, i= f the RC logs in, he would be able to manage his consent policies).=C2=A0
What you mention here is why I display RP-AS an= d RC-AS!
=C2=A0
So there's really no obligation = that B occurs through the GC and C occurs through the GS. It depends on whe= re your front-channel is located (GC, GS, third-party).
Yes. I agree with=C2=A0you. How can we make this=C2=A0 visible in= a diagram?

This I think makes it a very flexible model, w= hile enabling what we're after.=C2=A0
Yes.=
/Francis=C2=A0

Fabien=C2=A0


On Mon, Aug 17, 2020 at 4:38 AM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.= org> wrote:
Hello Dick,

Thanks for pointing this out. This is= the new diagram where=C2=A0++++ refers=C2=A0to what Endpoint/Human interac= tion and ----> refers to interaction among services.

=C2= =A0 =C2=A0 +-------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----------------+
=C2=A0 =C2=A0 | Re= questing =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0Resource =C2=A0 =C2=A0 =C2=A0|
=C2=A0= =C2=A0 | Party (RP) =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Controller (RC)|
=C2=A0 =C2=A0 += -------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+----------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 += =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = + =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0(= A) =C2=A0 =C2=A0 (B1) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0(C1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0= =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +. =C2=A0 =C2=A0 =C2=A0 = =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 +--------+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0= =C2=A0 =C2=A0 | RP-AS =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | RC-AS =C2=A0|<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 +--->| =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 +-->| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 + =C2=A0|=C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 | =C2=A0 +---= -----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 + (B0) =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0|=C2=A0 =C2=A0 =C2= =A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(C0) =C2=A0
=C2=A0 = =C2=A0 +--------+ =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+
=C2= =A0 =C2=A0 | Grant =C2=A0|--------(1)------|------------>| =C2=A0Resourc= e =C2=A0|
=C2=A0 =C2=A0 | Client | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 Server =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0(GC) =C2=A0| =C2=A0 =C2=A0 =C2= =A0 +---------------+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0(RS) =C2=A0 =C2= =A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--(2)->| =C2=A0 =C2= =A0 Grant =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(3)-= >| =C2=A0 =C2=A0 Server =C2=A0 =C2=A0|- (6) -| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(4)-= -| =C2=A0 =C2=A0 =C2=A0(GS) =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 +---------------+ =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------= --(5)------------->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2= =A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------------+


It is still = important to know what is part of the protocol:
Alt-1: only (1..6). This is what you specified in section 1.= 2, and I am fine with that.
Alt-2= : Alt-1=C2=A0+=C2=A0(B0, C0). This is a result of the discussion we have be= en having around privacy, GS as big brother, aso....

P.S.: an= authentication [RP]+++(A)+++>[GC] can be assumed, but shall be irreleva= nt for the protocol. [RP]+++(B1)+++>[RP-AS] is important for later insta= ntiation of the model. As in many cases, like in oAuth [RP-AS] could be the= same entity like [GS].

Best regards.<= /font>
/Francis


On Sun, Aug 16, 2020 at 7:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Fr= ancis

I was intentional in stating 1.3 that it is human = interactions. The connection lines are '+=C2=A0+=C2=A0+' rather tha= n '-----' to indicate that it is a human interaction rather than a = protocol between roles. We can't specify how a human interaction works,= but we can show when they might occur relative to the rest of the protocol=

In the abstract diagram in 1.3, I show the intera= ctions between the User and the GC, the User and the GS, and the RO and the= GS. These are NOT interactions that can be technically specified. The User= and RO are not roles in the protocol, but are entities in the trust model.=

I debated keeping the interactions abstract and n= ot stating=C2=A0"what" happened in each interaction, but thought = that might be confusing at this stage or our discussions.

Since it is just an interaction between human and software, we can = have the User authenticate to the GC as well as authorize (provide consent)= , and have no interaction at the GS. We would need to define how to represe= nt the authorization and the consent for the GC to pass to the GS, but the = roles and entities stay the same. The trust model does change though.
=

/Dick







On Sun, Aug 16, 2020 at 3:46 = PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,=C2=A0<= /font>my feedback below:

1.2: Excellent and Focussed
-&g= t; The word "Grant Client" looks great for me.

1.3:
Tit= le: Human Interaction -> End User Interaction
I would title this &quo= t;End User" interaction and not "human ...". It is not about= having a human, but a terminating edge of the protocol. An "End User&= quot; can be either human on an IOT device or a car or ...

Participa= nt: User -> "Requesting Party"
I will still insist on repla= cing the word "User" with a role name. Maybe "Requesting Par= ty" as used by UMA.

Participant: "Resource Controller"= ;. In past discussions there was a consensus on using "Resource Contro= ller" instead.

(B) I which the GS never interacts with the &quo= t;Requesting Party" in a matter of obtaining a grant to a resource (ma= ny reasons: privacy, confidentiality, abstraction, ...). Generally the GS w= ill need information (claims) about the "Requesting Party" to pro= ceed with the authorisation decision. In this case, the GS can instruct the= GC to obtain those claims. In some cases, claims on the "Requesting P= arty" will be obtained from another "Authorization Server" (= AS). The word AS is intentionally chosen here. In this same login, the path= (C0, C1) below will not only return the RC consent, but might also return = some claims on RC.

ASs provide authentication "of" and con= sent collection "from" End Users. End users are in this case the = Requesting Party, and the Resource Controller).

The result can look = like the modified diagram below. With this we can address some privacy conc= erns that are being discussed on the list.

=C2=A0 =C2=A0 +----------= ---+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+----------------+
=C2=A0 =C2=A0 | Requesting =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0Resource =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | Party (RP) = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Controller (RC)|
=C2=A0 =C2=A0 +-------------+ =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+----------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 + =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2= =A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +
=C2=A0 =C2=A0 =C2=A0 =C2=A0(A) =C2=A0 =C2=A0 (B1)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(C1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +. =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 +-= -------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 | RP-AS =C2= =A0| =C2=A0 =C2=A0 =C2=A0 | RC-AS =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0= =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2= =A0 =C2=A0 =C2=A0 (B0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+ =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 + = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(C0) =C2=A0
=C2= =A0 =C2=A0 +--------+ + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+
=C2=A0 = =C2=A0 | Grant =C2=A0| - - - -(1)- - - - + - - - - ->| =C2=A0Resource = =C2=A0|
=C2=A0 =C2=A0 | Client | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= Server =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0(GC) =C2=A0| =C2=A0 =C2=A0 =C2=A0= +---------------+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0(RS) =C2=A0 =C2=A0|<= br>=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--(2)->| =C2=A0 =C2=A0 Gr= ant =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(3)->| = =C2=A0 =C2=A0 Server =C2=A0 =C2=A0|- (6) -| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-(4)--| =C2= =A0 =C2=A0 =C2=A0(GS) =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 +---------------+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------(5)--= ----------->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2= =A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------------+

= (B0, B1) replace (B). Occur inside step (3), GS asks GC to collect the clai= ms. GC contacts RP-AS to negotiate those=C2=A0claims. But it is important t= o mention that those Claims-RP are not the target Grant being negotiated fo= r the resource access. They are generally=C2=A0used by GS (and later RS) as= input into performing authz decisions.

(C0, C1) replace (C).= They occur=C2=A0after step (3) (Beware of the difference=C2=A0to Bs that o= ccur=C2=A0inside 3). This separation address the Big Brother problem we hav= e been discussing in the list.
Essential is to mention that i= n an instantiation of this model for oAuth for example:
- GS, RP-AS and RC-AS might be the same entity.
- RP and RC might refer to the same &= quot;End User".=C2=A0

Of= f-topic: The splitting of GS and AS was suggested in some discussions on th= e mailing list. But we have no mean yet to isolate good inputs for later re= use. This is why I suggest we compile some inputs into tickets or wiki page= s (like use cases).

1.4:
The Trust model introduces what I would = rather call the trust framework. The purpose of the trust framework will be= to address topics mentioned in this section. There is still a lot of discu= ssion needed to have a structure for this section.


1.5
I sugg= est again we replace Human with "End User" and still make them ro= les. This is:
Terminology (Are all roles)
=C2=A0 -> These roles ca= n be borne by End Users
=C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)<= br>=C2=A0 =C2=A0 =C2=A0-> Resource Controller (RC)
=C2=A0 -> These= role can be borne by Services
=C2=A0 =C2=A0 =C2=A0-> GS
=C2=A0 = =C2=A0 =C2=A0-> GC
=C2=A0 =C2=A0 =C2=A0-> RS
=C2=A0 =C2=A0 =C2= =A0-> RP-AS
=C2=A0 =C2=A0 =C2=A0-> RC-AS

I will stop here, = as the fundamental agreement on this structure is necessary for a qualified= review of section 2++.

<= /font>
Best regards
/Francis

On Sat, Aug 15, 2020 at 7:03 PM = Dick Hardt <di= ck.hardt@gmail.com> wrote:
Hello

I just push= ed an updated version of XAuth:

<= div>
Highlights:
  • renamed Client -> Grant Clie= nt
  • 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 o= n Grant, and separate protocol roles from human interactions.
New introduction included below for your convenience

<= div>/Dick

    1.=C2=A0Introduction

    EDITOR NO= TE

    This doc= ument captures a number of concepts that may be adopted by the proposed GNA= P working group. Please refer to this document as:

    =

    XAuth

    <= p id=3D"m_-6756247088188955098gmail-m_8789399216572105611gmail-m_3993451923= 099602247gmail-m_-3253219048718590634gmail-m_-7491335305061859892gmail-m_-5= 602902245930246723gmail-m_-8634122456003472927gmail-section-1-4" style=3D"p= adding:0px;margin:0px 0px 1em">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 des= cribes the core Grant Negotiation and Authorization Protocol (GNAP). The pr= otocol supports the widely deployed use cases supported by OAuth 2.0=C2=A0<= span>[RFC6749]=C2=A0&=C2=A0[RFC6750], OpenID Connect=C2=A0[OIDC]=C2=A0- an extension o= f OAuth 2.0, as well as other extensions. Related documents include: GNAP -= Advanced Features=C2=A0[GNAP_Advanced]=C2=A0a= nd JOSE Authentication=C2=A0[JOSE_Authentication]=C2=A0that describes the JOSE mechanisms for client authenticatio= n.

    The technology landsc= ape has changed since OAuth 2.0 was initially drafted. More interactions ha= ppen on mobile devices than PCs. Modern browsers now directly support asyme= tric cryptographic functions. Standards have emerged for signing and encryp= ting tokens with rich payloads (JOSE) that are widely deployed.=

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

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

    The suggested pronuncia= tion of GNAP is "guh-nap".

    1.1.=C2=A0The Grant

    The Grant is at the center of the protocol between a client and a serve= r. A Grant Client requests a Grant from a Grant Server. The Grant Client an= d 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 a= dditional information to be included in the Grant Request.

    1.2.=C2=A0Prot= ocol Roles

    There are three roles = in GNAP: the Grant Client (GC), the Grant Server (GS), and the Resource Ser= ver (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 determi= ne 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_Authent= ication].

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

    (4) The GS returns a Grant to the GC (Grant Respons= e=C2=A0Section 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.

    1.3.=C2=A0Human Interactions

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

    Below is when th= e 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=A0<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#Prot= ocolRoles" style=3D"text-decoration-line:none;color:rgb(34,34,238)" target= =3D"_blank">Section 1.2. 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 que= ry the RS to determine what the RS requires from a GS for resource access

    (2) The GC makes a Gr= ant request to the GS

    (B) The GS may interact with the User for g= rant authorization

    (C) The GS may interact with the RO for grant authorizatio= n

    (4) The= GS returns a Grant to the GC

    (5) The GC accesses resources at the RS

    <= p id=3D"m_-6756247088188955098gmail-m_8789399216572105611gmail-m_3993451923= 099602247gmail-m_-3253219048718590634gmail-m_-7491335305061859892gmail-m_-5= 602902245930246723gmail-m_-8634122456003472927gmail-section-1.3-13" style= =3D"padding:0px;margin:0px 0px 1em">(6) The RS evaluates access granted by = the GS to determine access granted to the GC

    Alternatively, the Resource Owner could be a leg= al entity that has a software component that the Grant Server interacts wit= h for Grant authorization. This interaction is not in scope of this documen= t.

    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:

    These three e= ntities do not interact in the protocol, but are trusted by the User and th= e 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 aut= horization 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 issue= d by the RO

    (E) RO t= rusts 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 Serv= er=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 claim= s to the GC
      • acq= uires 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)

    Humans

    • User

    • the person interacting wi= th the Grant Client.
    • has delegated access to identity claims about themselves to the Grant= Server.
    • may au= thenticate at the GS...

  • Resource Owner= =C2=A0(RO)

    • Reused Terms=

    • access token=C2=A0- an ac= cess token as defined in=C2=A0[RFC6749]=C2=A0Section= 1.4.. An GC uses an access token for resource access at a RS.
    • Claim=C2=A0- a Cla= im 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 Regist= ered Client as defined in=C2=A0[RFC6749]=C2=A0Sectio= n 2.2.
    • ID Toke= n=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[RFC7519]=C2=A0Section 2.
    • au= thN=C2=A0- short for authentication.
    • authZ=C2=A0- short for authorizatio= n.

    N= ew Terms

    • GS URI=C2=A0- the= endpoint at the GS the GC calls to create a Grant, and is the unique ident= ifier for the GS.
    • Registered Client=C2=A0- a GC that has registered with the GS a= nd has a Client ID to identify itself, and can prove it possesses a key tha= t is linked to the Client ID. The GS may have different policies for what d= ifferent Registered Clients can request. A Registered Client MAY be interac= ting with a User.
    • Dynamic Client=C2=A0= - a GC that has not been previously registered with the GS, and each instan= ce will generate it's own asymetric key pair so it can prove it is the = same instance of the GC on subsequent requests.. The GS MAY return a Dynami= c Client a Client Handle for the Dynamic Client to identify itself in subse= quent requests. A single-page application with no active server component i= s 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 subse= quent requests.
    • Interaction=C2=A0- how the GC directs the User to interact with t= he GS. This document defines the interaction modes: "redirect", &= quot;indirect", and "user_code" in=C2=A0Secti= on 5.
    • Gran= t=C2=A0- the user identity claims and/or resource access the GS ha= s 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 G= S URI.
    • Access<= /strong>=C2=A0- the access granted by the RO to the GC and contains an acce= ss token. The GS may invalidate an Access at any time.
    • Access URI=C2=A0- the UR= I that represents the Access the GC was granted by the RO. The Access URI M= UST start with the GS URI.. The Access URI is used to refresh an access tok= en.


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


    --
    Francis Pouatcha
    Co-Founder and Technical Lead=
    adorsys GmbH & Co. KG


    --
    Francis Pouatcha
    Co-Founder and Technical Lead=
    adorsys GmbH & Co. KG
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


    --
    Francis Pouatcha
    Co-Founder and Technical Lead=
    adorsys GmbH & Co. KG
    --00000000000025f65b05ad111028--