From nobody Mon Aug 3 00:36:01 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 CB0713A0C31 for ; Mon, 3 Aug 2020 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.212 X-Spam-Level: ** X-Spam-Status: No, score=2.212 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no autolearn_force=no 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 QUzAmeItuOCD for ; Mon, 3 Aug 2020 00:35:57 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E253A0C30 for ; Mon, 3 Aug 2020 00:35:56 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d08 with ME id Avbt2300D2bcEcA03vbuBS; Mon, 03 Aug 2020 09:35:55 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 03 Aug 2020 09:35:55 +0200 X-ME-IP: 90.79.51.120 From: Denis To: Dick Hardt Cc: "txauth@ietf.org" Message-ID: Date: Mon, 3 Aug 2020 09:35:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B8761C8CAC6FB90B6037B4A9" Content-Language: en-GB Archived-At: Subject: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 03 Aug 2020 07:36:00 -0000 This is a multi-part message in MIME format. --------------B8761C8CAC6FB90B6037B4A9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Dick, This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11". Hereafter are three exchanges between you and me which triggered this new thread: [Dick]    The photo sharing example was a driving use case for the creation of OAuth. [Denis]  We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way. [Dick]   The use case is the same. Is there a different solution you are proposing ? My response is : Yes indeed, I have a different solution to address the same use case. RFC 6749 and draft-ietf-oauth-v2-1-00 both state: For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation-specific credentials (access token). There are no further explanations. Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials" is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client, the user will be unable to make sure that her instructions have been carefully followed. RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section. Thus, the leakage of information to the AS is not discussed. It is possible to revisit the original scenario by applying "Privacy by design" principles. The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993. RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client, a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able to act as Big Brother and this solves a major privacy concern. * The three entities involved * The Client supporting a User (was the Resource Owner). The Photo-sharing service (was the Resource Server) : RS1. The Printing service (was the client): RS2. * * *Flow of operations with the Photo-sharing service (RS1) *The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1). RS1 to User: "Please select the operation to be performed". Operation selected: "Print pictures using a third party printing service". RS1 to User: "Please select a set of pictures to be printed". The User selects the pictures. RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ? If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures". * Flow of operations with the Printing service* (*RS2) * The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2). _Note_: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account                       and that the prints can be sent to a known address. RS2 to User: "Please select the operation to be performed". Operation : "Print pictures to be received from a photo-sharing service ". RS2 to User: "Please indicate your photo-sharing service". The User responds: RS1. "Please enter the reference to be used by RS2 to receive the set of pictures from RS1". The Client (or the User) enters the reference generated by RS1. RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures). RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ? The User responds to all these questions. RS 2 User consent: This operation will be charged XX € ? Do you agree ? If the payment needs to be done on-line, then a payment phase is inserted. * Continuation of the flow of operations *Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2". Final message from RS2 to the Client: "Your prints will be soon on their way". RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference. * Some of the advantages of RDT* 1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1), without sharing her username and password with the printing service. 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue. 3. Any authentication method supported by RS1 or RS2 can be used by the User. 4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT. 5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2). 6. The reference generated by RS1 will only be accepted by RS1 during a time period. 7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1. 8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation. *Questions*: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ? Denis --------------B8761C8CAC6FB90B6037B4A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Dick,

This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]    The photo sharing example was a driving use case for the creation of OAuth.
[Denis]  We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]   The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed. 

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

            Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
                      and that the prints can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX € ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis

--------------B8761C8CAC6FB90B6037B4A9-- From nobody Mon Aug 3 04:15:42 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 C17683A0E53 for ; Mon, 3 Aug 2020 04:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qvlXHGDJXB2s for ; Mon, 3 Aug 2020 04:15:39 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 3F4B43A0E50 for ; Mon, 3 Aug 2020 04:15:39 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id l1so38074181ioh.5 for ; Mon, 03 Aug 2020 04:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CPutkGCMnphipXYfsKrdMQa/RVHWEDh5x7quBRW4pug=; b=BMa5V/fgzQvXYqukxjKxij3dguQyIEYqaVN5loqgtubToVZHwyLi67Gr9PwukdL9Vp INJvk6rxHzPAF5873tol2a+xYesA0MvFYH2I4yGT5xNVcQL9h7YAd0mKVFMd02eHVcVA wiPGKiwc+DYuvID9ekwXOp9gXJayUP5i2fpqO3OuqHd9aUrwb8gmFBdprsSOlctV2WRE IMMFOeMlH5mevs7NKjAICGJbqd64LZkGPOdGu7DKvrtjiVKMwAAsaTGKkue8G2VE45CQ OhWDSV7AvJuDFIK0ADducshgBxVZoU+dVdSjIpHwXDCIhUBCDTAepWTTJGUz4Ga1EmzJ aLcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CPutkGCMnphipXYfsKrdMQa/RVHWEDh5x7quBRW4pug=; b=UvwzVQEPV6OY0FLPa95DdIMA50gjr1cAKpYXqo5lSfo43xSjakW2UZUgsbhPetR0Ba cdp6Pwnuuu06HVjL2FxNrmGdtCturhUA8I+h4/1Re26d72ft8E5+wY2nyicSi2fiX9o3 SlQCHl1ITKdl+RZaYXeQdRrR0UblKCqX7JYVuc/uUmNZlJJFh8a04QrOb7QS5R0Hxk/w tojfdH4slt2127aRGZG/ONb+DgVbrNHdP1+bSNvsKIdNaNlhtRuj+6r2a6jE0I+PWqUV l/IGeS1dp7DMZLnChZ7SeRoXWwFw/YKPzbC+t6MOOWZrE7hp44t9FTrI1yI1egY9TGiA FeWQ== X-Gm-Message-State: AOAM531R7SIIUeaC++0rRA14DA7OxIWyLds7FnwbTXlZTQq2nCgrRN73 i7plJsud78Nx4qPVt5UFzWLvajUzrynr5fSwZBTh9lBJbwk= X-Google-Smtp-Source: ABdhPJxuk4NX5A73f6iZ6JE8ayK+ul9S38jxYzattI3bTGkne0n5EzePg5pxY57FFdU5vkAJN5RW9yQJZ2n1mRd0Hzs= X-Received: by 2002:a5d:841a:: with SMTP id i26mr16095900ion.144.1596453338412; Mon, 03 Aug 2020 04:15:38 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Mon, 3 Aug 2020 13:15:27 +0200 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000022fbb005abf74283" Archived-At: Subject: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 11:15:41 -0000 --00000000000022fbb005abf74283 Content-Type: text/plain; charset="UTF-8" Hello, This is a new thread. I have just published a proof of concept that separates the interaction from the rest of the AS. The goal is to open up the door to a privacy preserving flow such as the one suggested by Denis (the interaction may be handled by a Client endpoint, if it wishes), as well as to optimize the implementation to each concern (UX for consent vs authorization flows). Note that it ends up being an implementation detail as far as the Client is concerned, as the core request/response format wasn't changed from the original XYZ protocol. The code and documentation is available publicly at: https://github.com/acertio/mvp_gnap_interact The flow is sketched and explained at https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process Let me know what you think. Cheers Fabien --00000000000022fbb005abf74283 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

This is a new thread.=C2= =A0

I have just published a proof of concept that = separates the interaction from the rest of the AS. The goal is to open up t= he door to a privacy preserving flow such as the one suggested by Denis (th= e interaction may be handled by a Client endpoint, if it wishes), as well a= s to optimize the implementation to each concern (UX for consent vs authori= zation flows).=C2=A0

Note that it ends up being an= implementation detail as far as the Client is concerned, as the core reque= st/response format wasn't changed from the original XYZ protocol.
=

The code and documentation is available publicly at:


Let me know what you think.

Cheers
Fabien

--00000000000022fbb005abf74283-- From nobody Mon Aug 3 08:34:20 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 D11D93A0C09 for ; Mon, 3 Aug 2020 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 y7oaS4yUPMpk for ; Mon, 3 Aug 2020 08:34:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB363A0BCF for ; Mon, 3 Aug 2020 08:33:46 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 073FXi5R010991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Aug 2020 11:33:44 -0400 From: Justin Richer Message-Id: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_4080BEDB-8B0E-46B2-A5AB-1C416660342D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 3 Aug 2020 11:33:43 -0400 In-Reply-To: Cc: txauth@ietf.org To: Fabien Imbault References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 15:34:19 -0000 --Apple-Mail=_4080BEDB-8B0E-46B2-A5AB-1C416660342D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fabien, Thanks for writing this up, this is interesting work! So if I=E2=80=99m = reading this correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is = now also used to connect the consent component with the AS, right? I = like how it folds in the verification of components with a really simple = calculation, and that allows the steps to be chained together. I really = like that the extra steps don=E2=80=99t affect what the client needs to = know or what it has to do, so a server could deploy with or without this = and not change client behavior.=20 I have a couple questions about how you think this might play out in a = deployment: 1) Do you think the interact server would sign its request to the AS in = 7? Since it=E2=80=99s a direct HTTP POST this should be able to use any = of the signing/proof mechanisms that the rest of GNAP would use. 2) How does the interaction server get information about the consent = being gathered, in order to display the appropriate UI to the user? This = seems like it could be part of the exchange in 7/8 but I=E2=80=99m not = sure what the details would look like, any thoughts there? 3) How does the interaction server communicate the results of the = consent back to the AS? It seems like that would require a second round = trip. I=E2=80=99m particularly interested in this idea because it could allow = standardization of something that OAuth is really bad at: interaction = through components that are not accessed via web browser. Think of it = like this: you=E2=80=99ve got an AS that handles the tokens and managing = state and all that, but you=E2=80=99ve got an on-device app to handle = the actual consent and user interaction portions. Previously, I=E2=80=99d = hand-waved that they=E2=80=99d talk to each other somehow, but this = approach could give us a way for that on-device app to talk back to the = AS, get the information it needs to draw a UI, and continue the request = without it needing to have a full view of everything back at the server. =E2=80=94 Justin > On Aug 3, 2020, at 7:15 AM, Fabien Imbault = wrote: >=20 > Hello,=20 >=20 > This is a new thread.=20 >=20 > I have just published a proof of concept that separates the = interaction from the rest of the AS. The goal is to open up the door to = a privacy preserving flow such as the one suggested by Denis (the = interaction may be handled by a Client endpoint, if it wishes), as well = as to optimize the implementation to each concern (UX for consent vs = authorization flows).=20 >=20 > Note that it ends up being an implementation detail as far as the = Client is concerned, as the core request/response format wasn't changed = from the original XYZ protocol. >=20 > The code and documentation is available publicly at: > https://github.com/acertio/mvp_gnap_interact = >=20 > The flow is sketched and explained at = https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#proce= ss = >=20 > Let me know what you think. >=20 > Cheers >=20 > Fabien >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_4080BEDB-8B0E-46B2-A5AB-1C416660342D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Fabien,

Thanks for writing this up, this is interesting work! So if = I=E2=80=99m reading this correctly, the =E2=80=9Cinteract_ref=E2=80=9D = portion is now also used to connect the consent component with the AS, = right? I like how it folds in the verification of components with a = really simple calculation, and that allows the steps to be chained = together. I really like that the extra steps don=E2=80=99t affect what = the client needs to know or what it has to do, so a server could deploy = with or without this and not change client behavior. 

I have a couple = questions about how you think this might play out in a = deployment:

1) = Do you think the interact server would sign its request to the AS in 7? = Since it=E2=80=99s a direct HTTP POST this should be able to use any of = the signing/proof mechanisms that the rest of GNAP would use.
2) How does the interaction server get information about the = consent being gathered, in order to display the appropriate UI to the = user? This seems like it could be part of the exchange in 7/8 but I=E2=80=99= m not sure what the details would look like, any thoughts = there?
3) How does the interaction server = communicate the results of the consent back to the AS? It seems like = that would require a second round trip.


I=E2=80=99m particularly interested in this idea because it = could allow standardization of something that OAuth is really bad at: = interaction through components that are not accessed via web browser. = Think of it like this: you=E2=80=99ve got an AS that handles the tokens = and managing state and all that, but you=E2=80=99ve got an on-device app = to handle the actual consent and user interaction portions. Previously, = I=E2=80=99d hand-waved that they=E2=80=99d talk to each other somehow, = but this approach could give us a way for that on-device app to talk = back to the AS, get the information it needs to draw a UI, and continue = the request without it needing to have a full view of everything back at = the server.

 =E2=80=94 Justin

On Aug = 3, 2020, at 7:15 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello, 

This is a new thread. 

I have just published a = proof of concept that separates the interaction from the rest of the AS. = The goal is to open up the door to a privacy preserving flow such as the = one suggested by Denis (the interaction may be handled by a Client = endpoint, if it wishes), as well as to optimize the implementation to = each concern (UX for consent vs authorization flows). 

Note that it ends up = being an implementation detail as far as the Client is concerned, as the = core request/response format wasn't changed from the original XYZ = protocol.

The = code and documentation is available publicly at:
https://github.com/acertio/mvp_gnap_interact

The flow is sketched and = explained at https://github.com/acertio/mvp_gnap_interact/blob/master/Redire= ct.md#process

Let me know what you think.

Cheers

Fabien

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

= --Apple-Mail=_4080BEDB-8B0E-46B2-A5AB-1C416660342D-- From nobody Mon Aug 3 09:23: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 193143A0F35 for ; Mon, 3 Aug 2020 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 Kw-xafK_wNdv for ; Mon, 3 Aug 2020 09:23:06 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 4AE003A0F31 for ; Mon, 3 Aug 2020 09:23:06 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u126so1838423iod.12 for ; Mon, 03 Aug 2020 09:23:06 -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=dmi5UMuGhhb+z1WT6R6he8vy17s0XAQmC+WA4CvkZk0=; b=doj2BYd/Y5nyhlcbCSGNelBrakR0bSSRVq6fri9NDWz7dRDXY/jCYllQGmj7Dt/l3k mX9Or/Uia8rkqLyblnVNDmZ3rsaTFyAIF10J2Rek4kk3NQkzVQtQvrBJOib6kwrc7UgD o/wO4+C8Ka3/FUjJhIsRn46d7SWr8wr3HJhDcwPYq3i5jxp1vYS0dwhSkCzLZuERrMay lkSuJ1UY3oy4YoFIABhZImocZGRkV86qM8nn4GUiHPCnR1058MmVey1DqgPwrQQDFVAq iC//Ijv8rooyFkPPq7id8D/2OMGYtXUlddUQ1S3YYILT7evkHNNQ+oebX+qjFf1/YIGr xVsg== 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=dmi5UMuGhhb+z1WT6R6he8vy17s0XAQmC+WA4CvkZk0=; b=qfwMBDHTZka3qL8MmjoF4F0r7H4GMuewJw6nXRSH/0uBKE32XfBxxXOU3gOAQK+Rsr AeoWwdXdKzhTjW89z2fivUcJHLd8zR25vTaFyj+8p8sItJHGpyYP/fJuEZWav5+WCF3E KhH8dSCixXLSEek9NgBSu1Fa1gBE2Umtu1bSsQasQdDh1q3/DaoSZBtQfy+uIdiM9VAn sLuwyJzsjA9xVAwtxiYdtomW04iFFD4sJyjL6mFa81MXWXoV3OfR8eannygmwpDV0Q/r 42F4S42Y7xCP966TLJoNGzZvcfjRo0/CiryMc6RrO6hBA/3oMvR+SYly6mrj7c9eQtJr dmAQ== X-Gm-Message-State: AOAM532Idp+qFGX8TSnyFwqo5q8OEDcAGw2scI7M1PnGFzR+B7+uFp8e tya8xSqyvAFVRexkhir/IGykC9rcokO/wMwTkaCuUASq X-Google-Smtp-Source: ABdhPJz3ptlV8wv3qRvMtA7nWPyguw+mgKRblKFCBVpk3k4iJaZolhhDtQ7SVeEQQsqD/y2Hf5aM4rhggLevfvM+gO4= X-Received: by 2002:a05:6638:d46:: with SMTP id d6mr477667jak.124.1596471785557; Mon, 03 Aug 2020 09:23:05 -0700 (PDT) MIME-Version: 1.0 References: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> In-Reply-To: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> From: Fabien Imbault Date: Mon, 3 Aug 2020 18:22:54 +0200 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ac118005abfb8db6" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 16:23:08 -0000 --000000000000ac118005abfb8db6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Thanks for your feedback. The point is indeed to evaluate whether this opens up new capabilities. A preliminary response: 1) yes, we would have to sign the request, by any mean supported by GNAP. 2) right now it's pretty much hardcoded, which would be fine in some cases; but more generally the way that requirement is gathered into GNAP still needs to be worked out: probably the Client needs to do a first call to the RS before. This is important to know if we want to keep it as an implementation detail, that the Client may not even care about. Could be part of the request (the simplest, but is it fine with privacy requirement if we need to route through the AS?) or we could have continuation Tx specific to the consent component. 3) we have a very basic example (global yes/no) in which we didn't have to care (the flow either continues or stops), but indeed, we would need a second complete HTTP roundtrip (in a simple implementation) or allow more advanced communication patterns to reduce roundtrips (we have more flexibility since the Client in not in the loop here). There's currently a lot of work on 0-RTT in workgroups such as DIDComm and QUIC that we could leverage for some high perf scenarios. I'll work on a more advanced proposal for these, still a lot of work in order to keep things simple and stupid ;-) Cheers Fabien On Mon, Aug 3, 2020 at 5:33 PM Justin Richer wrote: > Fabien, > > Thanks for writing this up, this is interesting work! So if I=E2=80=99m r= eading > this correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is now also us= ed to connect the > consent component with the AS, right? I like how it folds in the > verification of components with a really simple calculation, and that > allows the steps to be chained together. I really like that the extra ste= ps > don=E2=80=99t affect what the client needs to know or what it has to do, = so a > server could deploy with or without this and not change client behavior. > > I have a couple questions about how you think this might play out in a > deployment: > > 1) Do you think the interact server would sign its request to the AS in 7= ? > Since it=E2=80=99s a direct HTTP POST this should be able to use any of t= he > signing/proof mechanisms that the rest of GNAP would use. > 2) How does the interaction server get information about the consent bein= g > gathered, in order to display the appropriate UI to the user? This seems > like it could be part of the exchange in 7/8 but I=E2=80=99m not sure wha= t the > details would look like, any thoughts there? > 3) How does the interaction server communicate the results of the consent > back to the AS? It seems like that would require a second round trip. > > > I=E2=80=99m particularly interested in this idea because it could allow > standardization of something that OAuth is really bad at: interaction > through components that are not accessed via web browser. Think of it lik= e > this: you=E2=80=99ve got an AS that handles the tokens and managing state= and all > that, but you=E2=80=99ve got an on-device app to handle the actual consen= t and user > interaction portions. Previously, I=E2=80=99d hand-waved that they=E2=80= =99d talk to each > other somehow, but this approach could give us a way for that on-device a= pp > to talk back to the AS, get the information it needs to draw a UI, and > continue the request without it needing to have a full view of everything > back at the server. > > =E2=80=94 Justin > > On Aug 3, 2020, at 7:15 AM, Fabien Imbault > wrote: > > Hello, > > This is a new thread. > > I have just published a proof of concept that separates the interaction > from the rest of the AS. The goal is to open up the door to a privacy > preserving flow such as the one suggested by Denis (the interaction may b= e > handled by a Client endpoint, if it wishes), as well as to optimize the > implementation to each concern (UX for consent vs authorization flows). > > Note that it ends up being an implementation detail as far as the Client > is concerned, as the core request/response format wasn't changed from the > original XYZ protocol. > > The code and documentation is available publicly at: > https://github.com/acertio/mvp_gnap_interact > > The flow is sketched and explained at > https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#proc= ess > > Let me know what you think. > > Cheers > > Fabien > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000ac118005abfb8db6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,=C2=A0

Thanks for your feedba= ck. The point is indeed to evaluate whether this opens up new capabilities.=

A preliminary response:=C2=A0

1) yes, we would have to sign the request, by any mean supported by G= NAP.=C2=A0
2) right now it's pretty much hardcoded, which wou= ld be fine in some cases; but more generally the way that requirement is ga= thered into GNAP still needs to be worked out: probably the Client needs to= do a first call to the RS before. This is important to know if we want to = keep it as an implementation detail, that the Client may not even care abou= t. Could be part of the request (the simplest, but is it fine with privacy = requirement if we need to route through the AS?) or we could have continuat= ion Tx specific to the consent component.=C2=A0
3) we have a very= basic example (global yes/no) in which we didn't have to care (the flo= w either continues or stops), but indeed, we would need a second complete H= TTP roundtrip (in a simple implementation) or allow more advanced communica= tion patterns to reduce roundtrips (we have more flexibility since the Clie= nt in not in the loop here). There's currently a lot of work on 0-RTT i= n workgroups such as DIDComm and QUIC that we could leverage for some high = perf scenarios.=C2=A0=C2=A0

I'll work on a mor= e advanced proposal for these, still a lot of work in order to keep things = simple and stupid ;-)

Cheers

<= div>Fabien

On Mon, Aug 3, 2020 at 5:33 PM Justin Richer <jricher@mit.edu> wrote:
Fabien,

Thanks for writing this up, this is inter= esting work! So if I=E2=80=99m reading this correctly, the =E2=80=9Cinterac= t_ref=E2=80=9D portion is now also used to connect the consent component wi= th the AS, right? I like how it folds in the verification of components wit= h a really simple calculation, and that allows the steps to be chained toge= ther. I really like that the extra steps don=E2=80=99t affect what the clie= nt needs to know or what it has to do, so a server could deploy with or wit= hout this and not change client behavior.=C2=A0

I = have a couple questions about how you think this might play out in a deploy= ment:

1) Do you think the interact server would si= gn its request to the AS in 7? Since it=E2=80=99s a direct HTTP POST this s= hould be able to use any of the signing/proof mechanisms that the rest of G= NAP would use.
2) How does the interaction server get information= about the consent being gathered, in order to display the appropriate UI t= o the user? This seems like it could be part of the exchange in 7/8 but I= =E2=80=99m not sure what the details would look like, any thoughts there?
3) How does the interaction server communicate the results of the = consent back to the AS? It seems like that would require a second round tri= p.


I=E2=80=99m particularly interes= ted in this idea because it could allow standardization of something that O= Auth is really bad at: interaction through components that are not accessed= via web browser. Think of it like this: you=E2=80=99ve got an AS that hand= les the tokens and managing state and all that, but you=E2=80=99ve got an o= n-device app to handle the actual consent and user interaction portions. Pr= eviously, I=E2=80=99d hand-waved that they=E2=80=99d talk to each other som= ehow, but this approach could give us a way for that on-device app to talk = back to the AS, get the information it needs to draw a UI, and continue the= request without it needing to have a full view of everything back at the s= erver.

=C2=A0=E2=80=94 Justin

On Aug 3, 2020, at 7:15 AM, Fabien Imbault <fabien.imbault@gma= il.com> wrote:

Hello,=C2=A0

<= /div>
This is a new thread.=C2=A0

I have just = published a proof of concept that separates the interaction from the rest o= f the AS. The goal is to open up the door to a privacy preserving flow such= as the one suggested by Denis (the interaction may be handled by a Client = endpoint, if it wishes), as well as to optimize the implementation to each = concern (UX for consent vs authorization flows).=C2=A0

=
Note that it ends up being an implementation detail as far as the Clie= nt is concerned, as the core request/response format wasn't changed fro= m the original XYZ protocol.

The code and document= ation is available publicly at:


Let= me know what you think.

Cheers

Fabien

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

--000000000000ac118005abfb8db6-- From nobody Mon Aug 3 10:15:34 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 31DB63A0F78 for ; Mon, 3 Aug 2020 10:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 6_tCoI8C4W7k for ; Mon, 3 Aug 2020 10:15:31 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 8F7063A0F72 for ; Mon, 3 Aug 2020 10:15:30 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v4so30814780ljd.0 for ; Mon, 03 Aug 2020 10:15:30 -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=dSC+qqDJU6zC+zzSieAlQNgphTQzmAAlyy0pzUuTY7I=; b=pxagjz8XVD/iw/VgYpDm9NY8UM3cwnD0hhOwwJP0paVS9ICBNHElGimrOJFK5t2AaP eQuph3LIC6TU77Ug3ecQLSSc6dluKfAzpc6Pi1zxA409TjZaYntsphtmZ+RH8BGGZ3Jd i8tNJlbdkc3wj2kPUSdA4kpUg+uROko7KrXSSeYofXhk0D09Ew39BYdZE17AqvjTHxXw fNzEyUIi7mpVsYevfbeY3qjz6WuCF7R2sIGP7R1tyhye0CcjAb77RppjwLeM8G6epIlK BeLBw6UMSfbUDKWTyk+hfHDrWv+4zMGhrC7pu/tHLyaGwH/xxrOunrylEVy2Q4Z/w80P vVGw== 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=dSC+qqDJU6zC+zzSieAlQNgphTQzmAAlyy0pzUuTY7I=; b=rX/6fa5s13zAzVGjUlGBAK4MYDSv1HFUCuPnDWNykGrfzEDfhfdlGrrp4Gj/hThOuR MhvDrRbSHxbAFopGKyCi4MM98TAPwA/VF2iD1PB9NjFufNCcXd6Ils236qqXJGGqwllB RXIgnJzVuk1IK0+XMcXKcZcUVHHnYZBSmQGBdOshNtGc5CLEGuA1+6mGc5Cuh5HGILJu YeiyNXPPPmZ0XIQYzR8IZ/viUTs1LI18kA7Dt/KFsnUY2HTCTvHIaIK9m92dle2AYfhd 34SCJghULBBSfH6tQo6UMLnuw6Ydmkyvpz7CWkV7JwVTKF+/qNCPe5XOh1uE2uuI1tgf MQcQ== X-Gm-Message-State: AOAM530ZBcb0fdR6sLV6fPhklicm9XDdetQF7Sz4L9S7deBhv31q4qeW E3JeV61uVOhEVsdoFSmG3RG24pm3P1WT5468nGbvPyfu X-Google-Smtp-Source: ABdhPJza3mC6yUuKdtvW/+cLQU3q4ZlUn4VR07uApIh8asT/SUj+pFISJoaf9eKx4u+rBmWBP2TXFPWxRDW0HH5jDEk= X-Received: by 2002:a2e:9695:: with SMTP id q21mr7594633lji.437.1596474928409; Mon, 03 Aug 2020 10:15:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 3 Aug 2020 10:14:52 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000032c805abfc49be" Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 03 Aug 2020 17:15:33 -0000 --0000000000000032c805abfc49be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis In your proposed flow, how does RS2 know who the user is that it is dealing with? In OAuth, the AS authenticates the User for the RS. In the photo sharing example, the AS and RS are from the same organization, so the AS knowing what the RS was doing was not an issue. What you call a Client is not an OAuth Client, but is more of an agent for the User. Microsoft InfoCards comes to mind as a comparable architecture, and it seems aligned with what Tom is asking for. On Mon, Aug 3, 2020 at 12:35 AM Denis wrote: > Hello Dick, > > This is a follow-up of the thread: "Reviewing > draft-hardt-xauth-protocol-11". > > Hereafter are three exchanges between you and me which triggered this new > thread: > > [Dick] The photo sharing example was a driving use case for the > creation of OAuth. > [Denis] We would need to revisit the original scenario and consider if i= t > can be addressed in a different way than the original way. > [Dick] The use case is the same. Is there a different solution you are > proposing ? > > My response is : Yes indeed, I have a different solution to address the > same use case. > > RFC 6749 and draft-ietf-oauth-v2-1-00 both state: > > For example, an end-user (resource owner) can grant a printing service > (client) access to her protected photos stored at > a photo-sharing service (resource server), without sharing her username > and password with the printing service. Instead, > she authenticates directly with a server trusted by the photo-sharing > service (authorization server), which issues the printing > service delegation-specific credentials (access token). > > There are no further explanations. > > Which information will be disclosed by the resource owner to the > authorization server to get "the printing service delegation-specific > credentials" > is not described. It is a private agreement between the AS and the RS. It > is more than likely that the authorization server will learn information > about which operation the resource owner is wishing to perform and where. > Since in OAuth, the access token is supposed to be opaque to the Client, > the user will be unable to make sure that her instructions have been > carefully followed. > > RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do > not contain a "Privacy Considerations" section. > Thus, the leakage of information to the AS is not discussed. > > It is possible to revisit the original scenario by applying "Privacy by > design" principles. > > The scenario can be solved by using an old data transfer method that has > been first described 32 years ago under the name > "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later > in ISO/IEC 10740-2:1993. > > RDT allows two servers to directly exchange large amounts of data under > the supervision of a client by communicating, through the client, > a reference generated by one server to the other server. RDT does not use > any Authorization Server (AS). This means that no AS is able > to act as Big Brother and this solves a major privacy concern. > > > * The three entities involved * > The Client supporting a User (was the Resource Owner). > The Photo-sharing service (was the Resource Server) : RS1. > The Printing service (was the client): RS2. > > > > *Flow of operations with the Photo-sharing service (RS1) *The Client > first connects to the photo-sharing service (RS1) and the User > authenticates to the photo-sharing service (RS1). > > RS1 to User: "Please select the operation to be performed". > Operation selected: "Print pictures using a third party printing service"= . > > RS1 to User: "Please select a set of pictures to be printed". > The User selects the pictures. > > RS 1 User consent: "Do you agree RS1 to communicate your selection of > pictures to a third party printing service" ? > If the User consents, RS1 to Client: "Here is the reference to be used by > your printing service to get the selected pictures". > > * Flow of operations with the Printing service* ( > *RS2) * > The Client connects to the printing service (RS2) and the User > authenticates to the printing service (RS2). > > *Note*: This allows to make sure that the user has an account > on RS2 so that further operations can be charged to this account > and that the prints can be sent to a known address. > > RS2 to User: "Please select the operation to be performed". > Operation : "Print pictures to be received from a photo-sharing service "= . > RS2 to User: "Please indicate your photo-sharing service". > The User responds: RS1. > > "Please enter the reference to be used by RS2 to receive the set of > pictures from RS1". > The Client (or the User) enters the reference generated by RS1. > > RS2 contacts RS1 using that reference in order to get the characteristics > and the thumbnails of the pictures to be printed (i.e. not yet the whole > pictures). > > RS2 to client: What are your printing preferences for each picture (e.g. > number of prints, size, quality of the paper, resolution, margins, colour= s, > etc... ) ? > The User responds to all these questions. > > RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do you a= gree ? > If the payment needs to be done on-line, then a payment phase is inserted= . > > > > * Continuation of the flow of operations *Final message from RS1 to the > Client: "Your selection of pictures will be soon transmitted to RS2". > Final message from RS2 to the Client: "Your prints will be soon on their > way". > > RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to > this reference. > > * Some of the advantages of RDT* > > 1. An end-user can grant a printing service (RS2) access to her > protected photos stored at a photo-sharing service (RS1), > without sharing her username and password with the printing service. > 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves > the Big Brother privacy issue. > 3. Any authentication method supported by RS1 or RS2 can be used by > the User. > 4. The User can use any photo-sharing service (RS1) with any printing > service (RS2), as long as they both support RDT. > 5. The User consent is first performed with the photo-sharing service > (RS1) and then after with the printing service (RS2). > 6. The reference generated by RS1 will only be accepted by RS1 during > a time period. > 7. The reference generated by RS1 allows RS2 to query first the > thumbnails and then after the pictures selected by the User at RS1. > 8. The data transfer of the pictures selected at RS1 by the User is > performed asynchronously from RS1 to RS2 as a back-office operation. > > *Questions*: What would be the full scenario of this use case using OAuth > ? What about Privacy Considerations ? > > Denis > > --0000000000000032c805abfc49be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis

In your proposed flow, how doe= s RS2 know who the user is that it is dealing with? In OAuth, the AS authen= ticates the User for the=C2=A0RS. In the photo sharing example, the AS and = RS are from the same organization, so the AS knowing=C2=A0what the RS was d= oing was not an issue.=C2=A0

What you call a Clien= t is not an OAuth Client, but is more of an agent for the User. Microsoft I= nfoCards comes to mind as a comparable architecture, and it seems aligned w= ith what Tom is asking for.





On Mon, Aug 3, 2020 at 12:35 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

Hello Dick,

This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]=C2=A0=C2=A0=C2=A0 The photo sharing example was a driving = use case for the creation of OAuth.
[Denis]=C2=A0 We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]=C2=A0=C2=A0 The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printin= g service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed.=C2=A0

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a= few years later in IS= O/IEC 10740-2:1993.=

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed&qu= ot;.
Operation selected: "Print pictures using a third party printi= ng service".

RS1 to User: "Please select a set of pictures to be printed&qu= ot;.
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and that the p= rints can be sent to a known address.

RS2 to User: "Please select the operation to be performed"= ;.
Operation : "Print pictures to be received from a photo-sharin= g service ".
RS2 to User: "Please indicate your photo-sharing service"= .
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the s= et of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do= you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor= RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authenticati= on method supported by RS1 or RS2 can be used by the User.
  4. The User can use= any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent= is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference ge= nerated by RS1 will only be accepted by RS1 during a time period.
  7. The reference ge= nerated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfe= r of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.=

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis

--0000000000000032c805abfc49be-- From nobody Mon Aug 3 10:28:19 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 9F3083A103C for ; Mon, 3 Aug 2020 10:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 Ir8uINSWQUt9 for ; Mon, 3 Aug 2020 10:28:14 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 7C33C3A0FF4 for ; Mon, 3 Aug 2020 10:28:09 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v9so6050864ljk.6 for ; Mon, 03 Aug 2020 10:28:09 -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=RXff8H0m1AIhHoFY9tVE0/WqUMhfGq5p6qv789YyZMI=; b=YBhRrdmZnUCa4bYhZRkazGiaa5ihuIzIj16k2j8/e3A/rXdyW1EyhhffY+d1khOlQY 6WoBx56VM65c8oCcr0KFSMdx8Hcv8St8vrOaq/aEg3xm+Q4mao8j3YYl2Ydj/w1HgAcg VwJWrzesd/+fr1ApGFoX3NggKcmdbr/UT8XtwF92dGdm7zYxJXpqju/fqjXTJx6ZLArs DqNII4WYvBvTObrRFfJ6IOODPSWMdCxXnsFKPx1K/eIG1Z14jLLVsE5o9XLqx7QEOhYH E2SSFaZV5NgUhesU7//2Uh39nidd3FKHYUdLtRviqWyy24WvrilRkVe3Mz7QTaDcJnTg tFzQ== 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=RXff8H0m1AIhHoFY9tVE0/WqUMhfGq5p6qv789YyZMI=; b=sCbxzBlpgm3Nw5/j34/ncCCCm3C/WBsqGWzvG3pu/tKejhjq2pmN90MBFQT4wa7Rcy w6cGwomZF59hqMdq8JjC/v6bE6X2qvec+BakQ0rSChxURZMcKa/hCnIfJvLptcHZTD6e FR1wUQha3nPsIQm03Lp8kinHw5U79ZfPY42ZIz1Lp2ViLXMN5ewA0wZmol51TQEdHPZq j+9y3FYVQc2209nNK/R3gylhx+sdq/fE7rKegcpjsBl+E0ChgP1Y2k+a3D1wOEbnGBdX DMmjTyZggW80/r/dOQzZcetrUshn4RulMuoAwlXQAngkQZi4ptJeRN/iO2r2zsUK2JC2 KPuA== X-Gm-Message-State: AOAM532X4FTK22WT8MMdXijDSfcVfhzWJZTSlPC+HwoTKKdI8MRRKarm XsKMQIZEwXKHm74pafrCE4S0C8EN9RvsKnttE0FGEGkr X-Google-Smtp-Source: ABdhPJzAanPHX7s0mGcE/vxjG9lIeu2K63tR1okGHqKFZqWU43CLKzO+CNo8a+gYv9DqrjBLckMj36gSXBQHaK+ohw8= X-Received: by 2002:a2e:999a:: with SMTP id w26mr8585167lji.242.1596475687385; Mon, 03 Aug 2020 10:28:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 3 Aug 2020 10:27:31 -0700 Message-ID: To: Fabien Imbault Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003d3e8d05abfc7620" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 17:28:18 -0000 --0000000000003d3e8d05abfc7620 Content-Type: text/plain; charset="UTF-8" Hi Fabien If I understand this correctly, you are factoring out the user authentication and consent from the AS issuing the access token. Correct? wrt. "the interaction handled by a Client endpoint" .. I think there is a conflation of the term Client ... software that can authenticate the user and act in the user's interest is NOT the GNAP Client. Perhaps Agent? ... it is a different component from the Client. On Mon, Aug 3, 2020 at 4:15 AM Fabien Imbault wrote: > Hello, > > This is a new thread. > > I have just published a proof of concept that separates the interaction > from the rest of the AS. The goal is to open up the door to a privacy > preserving flow such as the one suggested by Denis (the interaction may be > handled by a Client endpoint, if it wishes), as well as to optimize the > implementation to each concern (UX for consent vs authorization flows). > > Note that it ends up being an implementation detail as far as the Client > is concerned, as the core request/response format wasn't changed from the > original XYZ protocol. > > The code and documentation is available publicly at: > https://github.com/acertio/mvp_gnap_interact > > The flow is sketched and explained at > https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process > > Let me know what you think. > > Cheers > > Fabien > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000003d3e8d05abfc7620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Fabien

If I understand this cor= rectly, you are factoring out the user authentication=C2=A0and consent from= the AS issuing the access token. Correct?

wrt. &q= uot;the interaction handled by a Client endpoint" .. I think there is = a conflation of the term Client ... software that can authenticate the user= and act in the user's interest is NOT the GNAP Client. Perhaps Agent? = ... it is a different component from the Client.

<= br>

On Mon, Aug 3, 2020 at 4:15 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hello,= =C2=A0

This is a new thread.=C2=A0

<= div>I have just published a proof of concept that separates the interaction= from the rest of the AS. The goal is to open up the door to a privacy pres= erving flow such as the one suggested by Denis (the interaction may be hand= led by a Client endpoint, if it wishes), as well as to optimize the impleme= ntation to each concern (UX for consent vs authorization flows).=C2=A0

Note that it ends up being an implementation detail as= far as the Client is concerned, as the core request/response format wasn&#= 39;t changed from the original XYZ protocol.

The c= ode and documentation is available publicly at:

Let me know what you think.

Cheers

Fabien

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000003d3e8d05abfc7620-- From nobody Mon Aug 3 10:30:59 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 9BE493A0FAB for ; Mon, 3 Aug 2020 10:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 Ee4yONj4Pnz6 for ; Mon, 3 Aug 2020 10:30:55 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 937063A114F for ; Mon, 3 Aug 2020 10:30:29 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id e11so4301559otk.4 for ; Mon, 03 Aug 2020 10:30:29 -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=OCrFwou0+bsCEWjUaNZx+H9Q4BaEvf7jPA/HyASm1gE=; b=Ngl0AEDkWeGW4xoJeOccgCLkHMJCYMZyJJyPCd4y+dz0S8s9exHPpqEX4lLQ90EAKT QR920sSaZlpeQM4y33fnwEhl9RLE27B5zzngqAtwlPl7GCpXTB+SIVf9lj87FqCipVgm 7pqjbJ5O8qnVAF4B6yrNIvmam75BwHOXy/psaeombe2TlC8dfl6LbchL1EFGMw8io04Z CC6xH3K8S6FwqEnJxvEfHm0TRTPetZa1XHTpBm6ySQ1FUpjA6iNWB1A9JjUXzRHai1j3 8jXkaxTh7CB7OIjIwKrXmj5lpfaycfmDmb8Mi5mLddkrwrWEc+qSfU0sGnuWnzX0Hl0k pYvQ== 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=OCrFwou0+bsCEWjUaNZx+H9Q4BaEvf7jPA/HyASm1gE=; b=BfAger8x8hdwbmZgkVk0BVLiqrTosTYZZeuwkNfIAAZlp2f1eeSkm/hKGgbsnPcFTX 7fOPu21PI/kh1IBqOTOrmM6aWrQYIIzenkBuVvN+A0y3p0+jLGy8AadHmxsB3V+80FDQ OXJpLyk43BbR32+Oqj6Q2kcRIX03ynpNr+SSdgJ34NUPOYAwlcrjO/CTGRFaqlt5GxSV DihNgMVdi94s7GJfsU2wMRwkrM11FSS8pK8WGfLZJ7lNkzcKqTYvs5oMMW5mzL0xB1Ob +AKC0S2pRzeG+llum7EZElLAr/R8Hkj7SwTB3c9YMzp4dVqy8lqoK6kbMgGaeSdiN3oS qSNg== X-Gm-Message-State: AOAM53190QNoMt/7YJS/i7pfDA3HkpUjy2MvCYhdGVtdY0zZdRSSCvHN 9K5MqIAFSyt2voODxGbc/ut8RUBtSFBKCLxOnGc= X-Google-Smtp-Source: ABdhPJzmT7QVJmorzAJ+fTca7WcneprPN3Pdtwy4gGRBVEGmxt5TrI+A1vh1TK6A0+MVhVHapoVUd2DbckXjegfyf0s= X-Received: by 2002:a9d:a03:: with SMTP id 3mr13943813otg.87.1596475828668; Mon, 03 Aug 2020 10:30:28 -0700 (PDT) MIME-Version: 1.0 References: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> In-Reply-To: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> From: Tom Jones Date: Mon, 3 Aug 2020 10:30:17 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , txauth gnap Content-Type: multipart/alternative; boundary="000000000000a90d8405abfc7eef" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 17:30:58 -0000 --000000000000a90d8405abfc7eef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is an alternative to that consisting of two token "niblets", essentially signed and encoded tokens that are designed to be embedded in an az token. These can be viewed as lite-weight VCs. https://wiki.idesg.org/wiki/index.php/Delegation https://wiki.idesg.org/wiki/index.php/Delegation and the consent to create binding which can be viewed as the user doing dynamic registration. https://wiki.idesg.org/wiki/index.php/Consent_to_Create_Binding These are IMHO necessary to do distributed identity. thx ..Tom (mobile) On Mon, Aug 3, 2020, 8:34 AM Justin Richer wrote: > Fabien, > > Thanks for writing this up, this is interesting work! So if I=E2=80=99m r= eading > this correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is now also us= ed to connect the > consent component with the AS, right? I like how it folds in the > verification of components with a really simple calculation, and that > allows the steps to be chained together. I really like that the extra ste= ps > don=E2=80=99t affect what the client needs to know or what it has to do, = so a > server could deploy with or without this and not change client behavior. > > I have a couple questions about how you think this might play out in a > deployment: > > 1) Do you think the interact server would sign its request to the AS in 7= ? > Since it=E2=80=99s a direct HTTP POST this should be able to use any of t= he > signing/proof mechanisms that the rest of GNAP would use. > 2) How does the interaction server get information about the consent bein= g > gathered, in order to display the appropriate UI to the user? This seems > like it could be part of the exchange in 7/8 but I=E2=80=99m not sure wha= t the > details would look like, any thoughts there? > 3) How does the interaction server communicate the results of the consent > back to the AS? It seems like that would require a second round trip. > > > I=E2=80=99m particularly interested in this idea because it could allow > standardization of something that OAuth is really bad at: interaction > through components that are not accessed via web browser. Think of it lik= e > this: you=E2=80=99ve got an AS that handles the tokens and managing state= and all > that, but you=E2=80=99ve got an on-device app to handle the actual consen= t and user > interaction portions. Previously, I=E2=80=99d hand-waved that they=E2=80= =99d talk to each > other somehow, but this approach could give us a way for that on-device a= pp > to talk back to the AS, get the information it needs to draw a UI, and > continue the request without it needing to have a full view of everything > back at the server. > > =E2=80=94 Justin > > On Aug 3, 2020, at 7:15 AM, Fabien Imbault > wrote: > > Hello, > > This is a new thread. > > I have just published a proof of concept that separates the interaction > from the rest of the AS. The goal is to open up the door to a privacy > preserving flow such as the one suggested by Denis (the interaction may b= e > handled by a Client endpoint, if it wishes), as well as to optimize the > implementation to each concern (UX for consent vs authorization flows). > > Note that it ends up being an implementation detail as far as the Client > is concerned, as the core request/response format wasn't changed from the > original XYZ protocol. > > The code and documentation is available publicly at: > https://github.com/acertio/mvp_gnap_interact > > The flow is sketched and explained at > https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#proc= ess > > Let me know what you think. > > Cheers > > Fabien > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a90d8405abfc7eef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is an alternative to that consistin= g of two token "niblets", essentially=C2=A0signed and encoded tok= ens that are designed to be embedded in an az token. These can be viewed as= lite-weight VCs.

https://wiki.idesg.org/wiki/index= .php/Delegation

and the consent to create binding which can be v= iewed as the user doing dynamic registration.

These are IMHO necessary to do distr= ibuted identity.

thx ..Tom (mobile)

On Mon, Aug 3, 2020, 8:34 AM Justin = Richer <jricher@mit.edu> wrote:
Fabien,
Thanks for writing this up, this is interesting work! So i= f I=E2=80=99m reading this correctly, the =E2=80=9Cinteract_ref=E2=80=9D po= rtion is now also used to connect the consent component with the AS, right?= I like how it folds in the verification of components with a really simple= calculation, and that allows the steps to be chained together. I really li= ke that the extra steps don=E2=80=99t affect what the client needs to know = or what it has to do, so a server could deploy with or without this and not= change client behavior.=C2=A0

I have a couple que= stions about how you think this might play out in a deployment:
<= br>
1) Do you think the interact server would sign its request to= the AS in 7? Since it=E2=80=99s a direct HTTP POST this should be able to = use any of the signing/proof mechanisms that the rest of GNAP would use.
2) How does the interaction server get information about the consen= t being gathered, in order to display the appropriate UI to the user? This = seems like it could be part of the exchange in 7/8 but I=E2=80=99m not sure= what the details would look like, any thoughts there?
3) How doe= s the interaction server communicate the results of the consent back to the= AS? It seems like that would require a second round trip.


I=E2=80=99m particularly interested in this idea be= cause it could allow standardization of something that OAuth is really bad = at: interaction through components that are not accessed via web browser. T= hink of it like this: you=E2=80=99ve got an AS that handles the tokens and = managing state and all that, but you=E2=80=99ve got an on-device app to han= dle the actual consent and user interaction portions. Previously, I=E2=80= =99d hand-waved that they=E2=80=99d talk to each other somehow, but this ap= proach could give us a way for that on-device app to talk back to the AS, g= et the information it needs to draw a UI, and continue the request without = it needing to have a full view of everything back at the server.
=
=C2=A0=E2=80=94 Justin

On Aug 3, 2020, at 7:15 AM, Fabien Imbault <fabie= n.imbault@gmail.com> wrote:

Hello,=C2= =A0

This is a new thread.=C2=A0

I have just published a proof of concept that separates the interaction fr= om the rest of the AS. The goal is to open up the door to a privacy preserv= ing flow such as the one suggested by Denis (the interaction may be handled= by a Client endpoint, if it wishes), as well as to optimize the implementa= tion to each concern (UX for consent vs authorization flows).=C2=A0

Note that it ends up being an implementation detail as fa= r as the Client is concerned, as the core request/response format wasn'= t changed from the original XYZ protocol.

The code= and documentation is available publicly at:

=

Let= me know what you think.

Cheers

Fabien

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
<= /blockquote>

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--000000000000a90d8405abfc7eef-- From nobody Mon Aug 3 11:27:12 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 464A43A105E for ; Mon, 3 Aug 2020 11:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 VDQgRDMI-Qsv for ; Mon, 3 Aug 2020 11:27:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154AD3A105D for ; Mon, 3 Aug 2020 11:27:06 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 073IR4W6028436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Aug 2020 14:27:04 -0400 From: Justin Richer Message-Id: <085908D8-8D48-4BE5-818A-B5F1232950BA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B92C6396-8887-4E7E-90B1-ABF3099F0AA3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 3 Aug 2020 14:27:04 -0400 In-Reply-To: Cc: txauth@ietf.org To: Fabien Imbault References: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 18:27:09 -0000 --Apple-Mail=_B92C6396-8887-4E7E-90B1-ABF3099F0AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for the clarifications! Yes, I agree that with these = simplifications the protocol collapses quite nicely like this. I wonder = if this could be an area where GNAP could provide support for those that = need the extra connections but stay out of the way of those that don=E2=80= =99t =E2=80=94 like how token introspection allows a runtime query of a = token=E2=80=99s status and capabilities, but nobody=E2=80=99s suggesting = it be mandated for all systems (for what I hope are obvious reasons!). = Then perhaps just like introspection this could be an =E2=80=9Cinternal = protocol=E2=80=9D that interested AS=E2=80=99s would use, but whether or = not it got used wouldn=E2=80=99t affect the outside of the protocol. = This kind of functional layering is a really good design goal. Another thing, this makes me wonder if we should in fact split up the = role of what=E2=80=99s classically been the AS into two functional = roles. One part talks to the client, the other part interacts with the = user (interaction server?). The connection between these components is = what this =E2=80=9Cinternal protocol=E2=80=9D would define, though there = would be other ways to handle it if you wanted to, just like with = introspection. If you haven=E2=80=99t done so yet, I would recommend that you write up = some pages in the Use Cases wiki describing the kinds of things you=E2=80=99= re after: https://github.com/ietf-wg-gnap/general/wiki/Use-Cases =E2=80=94 Justin > On Aug 3, 2020, at 12:22 PM, Fabien Imbault = wrote: >=20 > Hi Justin,=20 >=20 > Thanks for your feedback. The point is indeed to evaluate whether this = opens up new capabilities. >=20 > A preliminary response:=20 >=20 > 1) yes, we would have to sign the request, by any mean supported by = GNAP.=20 > 2) right now it's pretty much hardcoded, which would be fine in some = cases; but more generally the way that requirement is gathered into GNAP = still needs to be worked out: probably the Client needs to do a first = call to the RS before. This is important to know if we want to keep it = as an implementation detail, that the Client may not even care about. = Could be part of the request (the simplest, but is it fine with privacy = requirement if we need to route through the AS?) or we could have = continuation Tx specific to the consent component.=20 > 3) we have a very basic example (global yes/no) in which we didn't = have to care (the flow either continues or stops), but indeed, we would = need a second complete HTTP roundtrip (in a simple implementation) or = allow more advanced communication patterns to reduce roundtrips (we have = more flexibility since the Client in not in the loop here). There's = currently a lot of work on 0-RTT in workgroups such as DIDComm and QUIC = that we could leverage for some high perf scenarios. =20 >=20 > I'll work on a more advanced proposal for these, still a lot of work = in order to keep things simple and stupid ;-) >=20 > Cheers >=20 > Fabien >=20 > On Mon, Aug 3, 2020 at 5:33 PM Justin Richer > wrote: > Fabien, >=20 > Thanks for writing this up, this is interesting work! So if I=E2=80=99m = reading this correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is = now also used to connect the consent component with the AS, right? I = like how it folds in the verification of components with a really simple = calculation, and that allows the steps to be chained together. I really = like that the extra steps don=E2=80=99t affect what the client needs to = know or what it has to do, so a server could deploy with or without this = and not change client behavior.=20 >=20 > I have a couple questions about how you think this might play out in a = deployment: >=20 > 1) Do you think the interact server would sign its request to the AS = in 7? Since it=E2=80=99s a direct HTTP POST this should be able to use = any of the signing/proof mechanisms that the rest of GNAP would use. > 2) How does the interaction server get information about the consent = being gathered, in order to display the appropriate UI to the user? This = seems like it could be part of the exchange in 7/8 but I=E2=80=99m not = sure what the details would look like, any thoughts there? > 3) How does the interaction server communicate the results of the = consent back to the AS? It seems like that would require a second round = trip. >=20 >=20 > I=E2=80=99m particularly interested in this idea because it could = allow standardization of something that OAuth is really bad at: = interaction through components that are not accessed via web browser. = Think of it like this: you=E2=80=99ve got an AS that handles the tokens = and managing state and all that, but you=E2=80=99ve got an on-device app = to handle the actual consent and user interaction portions. Previously, = I=E2=80=99d hand-waved that they=E2=80=99d talk to each other somehow, = but this approach could give us a way for that on-device app to talk = back to the AS, get the information it needs to draw a UI, and continue = the request without it needing to have a full view of everything back at = the server. >=20 > =E2=80=94 Justin >=20 >> On Aug 3, 2020, at 7:15 AM, Fabien Imbault > wrote: >>=20 >> Hello,=20 >>=20 >> This is a new thread.=20 >>=20 >> I have just published a proof of concept that separates the = interaction from the rest of the AS. The goal is to open up the door to = a privacy preserving flow such as the one suggested by Denis (the = interaction may be handled by a Client endpoint, if it wishes), as well = as to optimize the implementation to each concern (UX for consent vs = authorization flows).=20 >>=20 >> Note that it ends up being an implementation detail as far as the = Client is concerned, as the core request/response format wasn't changed = from the original XYZ protocol. >>=20 >> The code and documentation is available publicly at: >> https://github.com/acertio/mvp_gnap_interact = >>=20 >> The flow is sketched and explained at = https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#proce= ss = >>=20 >> Let me know what you think. >>=20 >> Cheers >>=20 >> Fabien >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_B92C6396-8887-4E7E-90B1-ABF3099F0AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you for the clarifications! Yes, I agree that with these = simplifications the protocol collapses quite nicely like this. I wonder = if this could be an area where GNAP could provide support for those that = need the extra connections but stay out of the way of those that don=E2=80= =99t =E2=80=94 like how token introspection allows a runtime query of a = token=E2=80=99s status and capabilities, but nobody=E2=80=99s suggesting = it be mandated for all systems (for what I hope are obvious reasons!). = Then perhaps just like introspection this could be an =E2=80=9Cinternal = protocol=E2=80=9D that interested AS=E2=80=99s would use, but whether or = not it got used wouldn=E2=80=99t affect the outside of the protocol. = This kind of functional layering is a really good design goal.

Another thing, this = makes me wonder if we should in fact split up the role of what=E2=80=99s = classically been the AS into two functional roles. One part talks to the = client, the other part interacts with the user (interaction server?). = The connection between these components is what this =E2=80=9Cinternal = protocol=E2=80=9D would define, though there would be other ways to = handle it if you wanted to, just like with introspection.

If you haven=E2=80=99t = done so yet, I would recommend that you write up some pages in the Use = Cases wiki describing the kinds of things you=E2=80=99re = after:

https://github.com/ietf-wg-gnap/general/wiki/Use-Cases

 =E2=80=94 = Justin

On Aug 3, 2020, at 12:22 PM, Fabien Imbault = <fabien.imbault@gmail.com> wrote:

Hi Justin, 
Thanks for your feedback. The point is = indeed to evaluate whether this opens up new capabilities.

A preliminary = response: 

1) yes, we would have to sign the request, by any mean = supported by GNAP. 
2) right now it's pretty = much hardcoded, which would be fine in some cases; but more generally = the way that requirement is gathered into GNAP still needs to be worked = out: probably the Client needs to do a first call to the RS before. This = is important to know if we want to keep it as an implementation detail, = that the Client may not even care about. Could be part of the request = (the simplest, but is it fine with privacy requirement if we need to = route through the AS?) or we could have continuation Tx specific to the = consent component. 
3) we have a very basic = example (global yes/no) in which we didn't have to care (the flow either = continues or stops), but indeed, we would need a second complete HTTP = roundtrip (in a simple implementation) or allow more advanced = communication patterns to reduce roundtrips (we have more flexibility = since the Client in not in the loop here). There's currently a lot of = work on 0-RTT in workgroups such as DIDComm and QUIC that we could = leverage for some high perf scenarios.  

I'll work on a more = advanced proposal for these, still a lot of work in order to keep things = simple and stupid ;-)

Cheers

Fabien

On Mon, Aug = 3, 2020 at 5:33 PM Justin Richer <jricher@mit.edu> wrote:
Fabien,

Thanks for writing this up, this is interesting work! So if = I=E2=80=99m reading this correctly, the =E2=80=9Cinteract_ref=E2=80=9D = portion is now also used to connect the consent component with the AS, = right? I like how it folds in the verification of components with a = really simple calculation, and that allows the steps to be chained = together. I really like that the extra steps don=E2=80=99t affect what = the client needs to know or what it has to do, so a server could deploy = with or without this and not change client behavior. 

I have a couple = questions about how you think this might play out in a = deployment:

1) = Do you think the interact server would sign its request to the AS in 7? = Since it=E2=80=99s a direct HTTP POST this should be able to use any of = the signing/proof mechanisms that the rest of GNAP would use.
2) How does the interaction server get information about the = consent being gathered, in order to display the appropriate UI to the = user? This seems like it could be part of the exchange in 7/8 but I=E2=80=99= m not sure what the details would look like, any thoughts = there?
3) How does the interaction server = communicate the results of the consent back to the AS? It seems like = that would require a second round trip.


I=E2=80=99m particularly interested in this idea because it = could allow standardization of something that OAuth is really bad at: = interaction through components that are not accessed via web browser. = Think of it like this: you=E2=80=99ve got an AS that handles the tokens = and managing state and all that, but you=E2=80=99ve got an on-device app = to handle the actual consent and user interaction portions. Previously, = I=E2=80=99d hand-waved that they=E2=80=99d talk to each other somehow, = but this approach could give us a way for that on-device app to talk = back to the AS, get the information it needs to draw a UI, and continue = the request without it needing to have a full view of everything back at = the server.

 =E2=80=94 Justin

On Aug = 3, 2020, at 7:15 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello, 

This is a new = thread. 

I = have just published a proof of concept that separates the interaction = from the rest of the AS. The goal is to open up the door to a privacy = preserving flow such as the one suggested by Denis (the interaction may = be handled by a Client endpoint, if it wishes), as well as to optimize = the implementation to each concern (UX for consent vs authorization = flows). 

Note that it ends up being an implementation detail as far as = the Client is concerned, as the core request/response format wasn't = changed from the original XYZ protocol.

The code and documentation is available = publicly at:
https://github.com/acertio/mvp_gnap_interact

The flow is sketched and = explained at https://github.com/acertio/mvp_gnap_interact/blob/master/Redire= ct.md#process

Let me know what you think.

Cheers

Fabien

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


= --Apple-Mail=_B92C6396-8887-4E7E-90B1-ABF3099F0AA3-- From nobody Mon Aug 3 12:02:22 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 602833A0A6D for ; Mon, 3 Aug 2020 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 itydWNl6mWI4 for ; Mon, 3 Aug 2020 12:02:19 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4D33A0A6A for ; Mon, 3 Aug 2020 12:02:18 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 073J2BoC010490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Aug 2020 15:02:12 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_44F70B26-F1AC-4B7D-992D-EE6920C1E716" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 3 Aug 2020 15:02:11 -0400 In-Reply-To: Cc: Dick Hardt , "txauth@ietf.org" To: Denis References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 03 Aug 2020 19:02:21 -0000 --Apple-Mail=_44F70B26-F1AC-4B7D-992D-EE6920C1E716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Denis, I think there=E2=80=99s still a problem with the terminology in use = here. What you describe as RS2, which might in fact be an RS unto = itself, is a =E2=80=9CClient=E2=80=9D in OAuth parlance because it is a = client of RS1. What you call a =E2=80=9Cclient=E2=80=9D has no analogue = in the OAuth world, but it is not at all the same as an OAuth client. I = appreciate your mapping of the entities below, but it makes it difficult = to hold a discussion if we aren=E2=80=99t using the same terms. The good news is that this isn=E2=80=99t OAuth, and as a new WG we can = define our own terms. The bad news is that this is really hard to do. In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions, but we=E2=80=99ve got a chance to be more precise with how = we define things. This could mean splitting up things into multiple = roles, or defining new roles for aspects that weren=E2=80=99t in = consideration in the protocol previously. Perhaps what you=E2=80=99re = calling a client below could potentially be considered the = =E2=80=9Cinteraction component=E2=80=9D or =E2=80=9Cconsent gatherer=E2=80= =9D, which was previously a portion of the AS.=20 I=E2=80=99ve never been a fan of the term =E2=80=9Cclient=E2=80=9D in = OAuth because it=E2=80=99s too generic and confusing to a lot of = developers, especially the web programmers that OAuth is aimed at. = =E2=80=9CUser Agent=E2=80=9D would be similarly unsuitable for the same = reasons =E2=80=94 both =E2=80=9Cclient=E2=80=9D and =E2=80=9Cuser = agent=E2=80=9D are taken to mean =E2=80=9Cbrowser=E2=80=9D in many = circles. I=E2=80=99d love for us to come up with a new term for this, = but apart from the =E2=80=9CResource Client (RC)=E2=80=9D that I = proposed in the XYZ Draft, I don=E2=80=99t have an answer. =E2=80=94 Justin > On Aug 3, 2020, at 3:35 AM, Denis wrote: >=20 > Hello Dick, >=20 >=20 > This is a follow-up of the thread: "Reviewing = draft-hardt-xauth-protocol-11". >=20 > Hereafter are three exchanges between you and me which triggered this = new thread: >=20 > [Dick] The photo sharing example was a driving use case for the = creation of OAuth. > [Denis] We would need to revisit the original scenario and consider = if it can be addressed in a different way than the original way. > [Dick] The use case is the same. Is there a different solution you = are proposing ? >=20 > My response is : Yes indeed, I have a different solution to address = the same use case. >=20 > RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >=20 > For example, an end-user (resource owner) can grant a printing service = (client) access to her protected photos stored at=20 > a photo-sharing service (resource server), without sharing her = username and password with the printing service. Instead,=20 > she authenticates directly with a server trusted by the photo-sharing = service (authorization server), which issues the printing=20 > service delegation-specific credentials (access token). >=20 > There are no further explanations.=20 >=20 > Which information will be disclosed by the resource owner to the = authorization server to get "the printing service delegation-specific = credentials"=20 > is not described. It is a private agreement between the AS and the RS. = It is more than likely that the authorization server will learn = information=20 > about which operation the resource owner is wishing to perform and = where. Since in OAuth, the access token is supposed to be opaque to the = Client,=20 > the user will be unable to make sure that her instructions have been = carefully followed. =20 >=20 > RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they = do not contain a "Privacy Considerations" section.=20 > Thus, the leakage of information to the AS is not discussed. >=20 > It is possible to revisit the original scenario by applying "Privacy = by design" principles.=20 >=20 > The scenario can be solved by using an old data transfer method that = has been first described 32 years ago under the name=20 > "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years = later in ISO/IEC 10740-2:1993. >=20 > RDT allows two servers to directly exchange large amounts of data = under the supervision of a client by communicating, through the client,=20= > a reference generated by one server to the other server. RDT does not = use any Authorization Server (AS). This means that no AS is able=20 > to act as Big Brother and this solves a major privacy concern. >=20 > The three entities involved >=20 > The Client supporting a User (was the Resource Owner). > The Photo-sharing service (was the Resource Server) : RS1.=20 > The Printing service (was the client): RS2. >=20 >=20 > Flow of operations with the Photo-sharing service (RS1) >=20 > The Client first connects to the photo-sharing service (RS1) and the = User authenticates to the photo-sharing service (RS1). >=20 > RS1 to User: "Please select the operation to be performed". > Operation selected: "Print pictures using a third party printing = service". >=20 > RS1 to User: "Please select a set of pictures to be printed". > The User selects the pictures. >=20 > RS 1 User consent: "Do you agree RS1 to communicate your selection of = pictures to a third party printing service" ? > If the User consents, RS1 to Client: "Here is the reference to be used = by your printing service to get the selected pictures". >=20 > Flow of operations with the Printing service (RS2) >=20 > The Client connects to the printing service (RS2) and the User = authenticates to the printing service (RS2). >=20 > Note: This allows to make sure that the user has an = account on RS2 so that further operations can be charged to this account=20= > and that the prints can be sent to a known = address. >=20 > RS2 to User: "Please select the operation to be performed". > Operation : "Print pictures to be received from a photo-sharing = service ". > RS2 to User: "Please indicate your photo-sharing service". > The User responds: RS1. >=20 > "Please enter the reference to be used by RS2 to receive the set of = pictures from RS1". > The Client (or the User) enters the reference generated by RS1. >=20 > RS2 contacts RS1 using that reference in order to get the = characteristics and the thumbnails of the pictures to be printed (i.e. = not yet the whole pictures).=20 >=20 > RS2 to client: What are your printing preferences for each picture = (e.g. number of prints, size, quality of the paper, resolution, margins, = colours, etc... ) ? > The User responds to all these questions. >=20 > RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do = you agree ? > If the payment needs to be done on-line, then a payment phase is = inserted. >=20 > Continuation of the flow of operations >=20 > Final message from RS1 to the Client: "Your selection of pictures will = be soon transmitted to RS2". > Final message from RS2 to the Client: "Your prints will be soon on = their way". >=20 > RS2 to RS1 (asynchronous): transmit the set of pictures corresponding = to this reference. >=20 > Some of the advantages of RDT >=20 > An end-user can grant a printing service (RS2) access to her protected = photos stored at a photo-sharing service (RS1), > without sharing her username and password with the printing service. > Neither RS1, nor RS2 need to use or to trust any AS. This solves the = Big Brother privacy issue. > Any authentication method supported by RS1 or RS2 can be used by the = User. > The User can use any photo-sharing service (RS1) with any printing = service (RS2), as long as they both support RDT. > The User consent is first performed with the photo-sharing service = (RS1) and then after with the printing service (RS2). > The reference generated by RS1 will only be accepted by RS1 during a = time period. > The reference generated by RS1 allows RS2 to query first the = thumbnails and then after the pictures selected by the User at RS1. > The data transfer of the pictures selected at RS1 by the User is = performed asynchronously from RS1 to RS2 as a back-office operation. > Questions: What would be the full scenario of this use case using = OAuth ? What about Privacy Considerations ? >=20 > Denis >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_44F70B26-F1AC-4B7D-992D-EE6920C1E716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Denis,

I think = there=E2=80=99s still a problem with the terminology in use here. What = you describe as RS2, which might in fact be an RS unto itself, is a = =E2=80=9CClient=E2=80=9D in OAuth parlance because it is a = client of RS1. What you call a =E2=80=9Cclient=E2=80=9D has no = analogue in the OAuth world, but it is not at all the same as an OAuth = client. I appreciate your mapping of the entities below, but it makes it = difficult to hold a discussion if we aren=E2=80=99t using the same = terms.

The = good news is that this isn=E2=80=99t OAuth, and as a new WG we can = define our own terms. The bad news is that this is really hard to = do.

In GNAP, = we shouldn=E2=80=99t just re-use existing terms with new definitions, = but we=E2=80=99ve got a chance to be more precise with how we define = things. This could mean splitting up things into multiple roles, or = defining new roles for aspects that weren=E2=80=99t in consideration in = the protocol previously. Perhaps what you=E2=80=99re calling a client = below could potentially be considered the =E2=80=9Cinteraction = component=E2=80=9D or =E2=80=9Cconsent gatherer=E2=80=9D, which was = previously a portion of the AS. 

I=E2=80=99ve never been a fan of the = term =E2=80=9Cclient=E2=80=9D in OAuth because it=E2=80=99s too generic = and confusing to a lot of developers, especially the web programmers = that OAuth is aimed at. =E2=80=9CUser Agent=E2=80=9D would be similarly = unsuitable for the same reasons =E2=80=94 both =E2=80=9Cclient=E2=80=9D = and =E2=80=9Cuser agent=E2=80=9D are taken to mean =E2=80=9Cbrowser=E2=80=9D= in many circles. I=E2=80=99d love for us to come up with a new term for = this, but apart from the =E2=80=9CResource Client (RC)=E2=80=9D that I = proposed in the XYZ Draft, I don=E2=80=99t have an answer.

 =E2=80=94 = Justin

On Aug 3, 2020, at 3:35 AM, Denis <denis.ietf@free.fr> = wrote:

=20

Hello Dick,


This is a follow-up of the = thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]    The photo sharing example was a = driving use case for the creation of OAuth.
[Denis]  We would need to revisit the original scenario = and consider if it can be addressed in a different way than the original way.
[Dick]   The use case is the same. Is there a = different solution you are proposing ?

My response is : Yes indeed, I = have a different solution to address the same use case.

RFC 6749 and = draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be = disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed. 

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by = using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC = 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client, =
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : = RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

          &nb= sp; Note: This allows to make sure that the user = has an account on RS2 so that further operations can be charged to this account
=             &n= bsp;         and that the prints = can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by = RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82=AC ? = Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be = soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1. =
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office = operation.

Questions: What would be the full scenario of = this use case using OAuth ? What about Privacy Considerations ?

Denis
=

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

= --Apple-Mail=_44F70B26-F1AC-4B7D-992D-EE6920C1E716-- From nobody Mon Aug 3 12:07:05 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 2D6B73A1066 for ; Mon, 3 Aug 2020 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 oPvVqKmIcjYY for ; Mon, 3 Aug 2020 12:07:03 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 5FBFC3A1062 for ; Mon, 3 Aug 2020 12:07:03 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id t18so32089978ilh.2 for ; Mon, 03 Aug 2020 12:07:03 -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=ft9PhH62bux+ms7cmLzOHrBVBaxajHPB3ytHTR2N6Tw=; b=KVz7PrU85d4R0H6kJI+OsqoK1f/AgAHB88UZXEpl9WmAh+dePobfCPN45uCFzzJoTy itZ+d0368gCo9c4i+81AQ228Boqcur6iw7jLxPJAHg5r+dFqgnZiNSBcuZMM8oYLkFMq sL2agWlNowHc6O6bt6snBjsbN5NJVX0AheRW3wxpOfwkmTWI9U5lfY3KBwX5pKMxXrJ7 TGqwda7TA+fJWuOmbfnJfaE3QVwQ3ZRa3rQipAcnJWV5nJk8k+PgSxSMyGbPpyTPnHK9 ElgK6RAevhtmjXe4cl6aKnOXRu9iREi5qT7G+rYIHWtntLVXeleZUojtBVj4bAzFKWvo BlBA== 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=ft9PhH62bux+ms7cmLzOHrBVBaxajHPB3ytHTR2N6Tw=; b=tg592RBP3m1RJNNtKfmuw88o/YrZOkswrku8zUtLrt0nJkdK+DTnazkxmb1mUmLCla oP4Yd7ITbsjfKwlmoak+rPUso7eSiqDlsuD0GR6ueqRXp644+6S+PJeMe7uKX4YhQu/p 3UsMN+f5bkMWn2aJ47+LNmzldxWDO5A/+ackrR8UpwIoKB0CAbosGokWkrCMd/bQO7Gv NRg3p3Wl3Ew8Ia17eUvwsg7s0KNho60pm0JQyyoLmV7Yj7BAWAdKUiuX4Ep3kWbfCxfN dyVAR4JPY3xB5j2Tj1tfS3WJEmdkFfuLL2PRCE0zMb7RttUXyzQp7mD9zJHqhwFuqMqG z6Hg== X-Gm-Message-State: AOAM533sAx0q09wqx9p9GEM/Nlt49axrQZkFYU+vdxohp/EKfjdqZMoY GuF6RsxCKKdUDWxSBtHn0MXpxc/QCItE6cciaN4I17EC X-Google-Smtp-Source: ABdhPJyMG+7o3UqjXnFXsOoyC22Pg6oQlzP8m8cihLnPw/gps+FmwLDOBEQs5yO1bUb5Q5So17G2mnC1+wD2QNn3IqM= X-Received: by 2002:a05:6e02:8:: with SMTP id h8mr846091ilr.188.1596481622555; Mon, 03 Aug 2020 12:07:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 3 Aug 2020 21:06:43 +0200 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000000c0e505abfdd8f9" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 19:07:05 -0000 --00000000000000c0e505abfdd8f9 Content-Type: text/plain; charset="UTF-8" Hi Dick, Yes correct. For 2 reasons : it's a pain (not very secure, not very scalable) to have to mix front end and back end + it started as an exercise following discussions with Denis (consent made by Client). In the context, I meant Client. The flow could be started by a request from the Client, just like it is currently in standard XYZ, but with an additional optional parameter in case it wishes to use a specific interact server (instead of the one embedded or chosen by the AS). And then there's really the Agent, which is indeed different from the Client, you're right. Fabien On Mon, Aug 3, 2020 at 7:28 PM Dick Hardt wrote: > Hi Fabien > > If I understand this correctly, you are factoring out the user > authentication and consent from the AS issuing the access token. Correct? > > wrt. "the interaction handled by a Client endpoint" .. I think there is a > conflation of the term Client ... software that can authenticate the user > and act in the user's interest is NOT the GNAP Client. Perhaps Agent? ... > it is a different component from the Client. > > > > On Mon, Aug 3, 2020 at 4:15 AM Fabien Imbault > wrote: > >> Hello, >> >> This is a new thread. >> >> I have just published a proof of concept that separates the interaction >> from the rest of the AS. The goal is to open up the door to a privacy >> preserving flow such as the one suggested by Denis (the interaction may be >> handled by a Client endpoint, if it wishes), as well as to optimize the >> implementation to each concern (UX for consent vs authorization flows). >> >> Note that it ends up being an implementation detail as far as the Client >> is concerned, as the core request/response format wasn't changed from the >> original XYZ protocol. >> >> The code and documentation is available publicly at: >> https://github.com/acertio/mvp_gnap_interact >> >> The flow is sketched and explained at >> https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#process >> >> Let me know what you think. >> >> Cheers >> >> Fabien >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000000c0e505abfdd8f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,=C2=A0

Yes correct. For 2 reaso= ns : it's a pain (not very secure, not very scalable) to have to mix fr= ont end and back end=C2=A0+ it started as an exercise following discussions= with Denis (consent made by Client).=C2=A0

In the= context, I meant Client. The flow could be started by a request from the C= lient, just like it is currently in standard XYZ, but with an additional op= tional parameter in case it wishes to use a specific interact server (inste= ad of the one embedded or chosen by the AS).

And t= hen there's really the Agent, which is indeed different from the Client= , you're right.

Fabien

On Mon, Aug 3,= 2020 at 7:28 PM Dick Hardt <dic= k.hardt@gmail.com> wrote:
Hi=C2=A0Fabien

If I un= derstand this correctly, you are factoring out the user authentication=C2= =A0and consent from the AS issuing the access token. Correct?
wrt. "the interaction handled by a Client endpoint" .= . I think there is a conflation of the term Client ... software that can au= thenticate the user and act in the user's interest is NOT the GNAP Clie= nt. Perhaps Agent? ... it is a different component from the Client.



On Mon, Aug 3, 2020 at 4:15 AM Fabien Imbault= <fabien.i= mbault@gmail.com> wrote:
Hello,=C2=A0

This is a = new thread.=C2=A0

I have just published a proof of= concept that separates the interaction from the rest of the AS. The goal i= s to open up the door to a privacy preserving flow such as the one suggeste= d by Denis (the interaction may be handled by a Client endpoint, if it wish= es), as well as to optimize the implementation to each concern (UX for cons= ent vs authorization flows).=C2=A0

Note that it en= ds up being an implementation detail as far as the Client is concerned, as = the core request/response format wasn't changed from the original XYZ p= rotocol.

The code and documentation is available p= ublicly at:
https://github.com/acertio/mvp_gnap_interact


Let me know what you th= ink.

Cheers

Fabien
<= div>
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000000c0e505abfdd8f9-- From nobody Mon Aug 3 12:07:49 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 B614B3A1066 for ; Mon, 3 Aug 2020 12:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 hrwSLJZH60GW for ; Mon, 3 Aug 2020 12:07:45 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 B33C73A1062 for ; Mon, 3 Aug 2020 12:07:45 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id z17so16962020ill.6 for ; Mon, 03 Aug 2020 12:07:45 -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=5m/p2rVRhmdSREFlnnb4NpJcFSkztjmoL4q/lzm+SZw=; b=Olb6nbAqa900AG7EePz3ExVPldIPmDPb2dQ++rJcEA/QKzjIz6vPua1HNuhXrcjuQS qCUUDKA/B3DcClY8U1LC0SoeOc5T4ekggBc9mYB06tT4fFody+VswLUuc4YYnx8N237G 7q1jBlkBkFoKJi69fz3YiJIi2X28jL2Zo250ClfBuRb9qBnI2EkWjevNiCEiP7YtuAfz v/hBx9Z9DwLoLuai/mVqGv2Hp81yonI5puGDPJxRnWKjxfEVZ51I/P7+Oz49Ih+hsi3q GI8+4txL4Upd2OoaeoI2bv+iGbSMrCafDTYO2H8w8sw/Ham2ew4mFxh4Hfc4FGWvGLGf GPVA== 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=5m/p2rVRhmdSREFlnnb4NpJcFSkztjmoL4q/lzm+SZw=; b=VyP3Gi/A+D9rgzNIIJ0eVIdW4xnvERfXKijEnQnfiyUXFuWm6xiSEVEYJNF3T6g3iQ SPWN5p27SwpMiLzhD7PnuusMmpmc6JIEXyVgSLQBMkNip9Nh3pbouyl8G7c8n5wrPpSh +14BBa0O6UwRcMYnoLMDEuAUJqVuzvXsESsGf/vtAJseiV0Ge+neL+pzPP0SF5VuOf2s 3tsMExgtuUyXamYMis0g2CTZvpAd9KHbXat91gz/ZeePye9alilqkvhGXBAQz3etZCgB VWbuB8mGQlUIgYp+fotg5TfzJiZamj4FRMnxP2EigjxGiEnxBFXAsQxCkresLnsnd+nV fN1Q== X-Gm-Message-State: AOAM532hz0pJ4xELmZGA+G4zN0vnzSSqEzGOM5idL/RgMVCjqLpypMVV Wka9+p+uAj5rgkU5qd5r6SUQDkn2+Mv0ZWFDQJ0= X-Google-Smtp-Source: ABdhPJzpPd6VNh68y4BQjop09DPmTkDGV8RUhrZh7WAQp+QO0CocbJCGqiDxhBHchtb0jg626Q5XtSWiidA7PhW5x4s= X-Received: by 2002:a92:35c8:: with SMTP id c69mr930306ilf.289.1596481665035; Mon, 03 Aug 2020 12:07:45 -0700 (PDT) MIME-Version: 1.0 References: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 3 Aug 2020 21:07:26 +0200 Message-ID: To: Tom Jones Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="00000000000089024805abfdda22" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 03 Aug 2020 19:07:48 -0000 --00000000000089024805abfdda22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the references Tom, will definitely check them out. Fabien On Mon, Aug 3, 2020 at 7:30 PM Tom Jones wrote: > Here is an alternative to that consisting of two token "niblets", > essentially signed and encoded tokens that are designed to be embedded in > an az token. These can be viewed as lite-weight VCs. > https://wiki.idesg.org/wiki/index.php/Delegation > > https://wiki.idesg.org/wiki/index.php/Delegation > > and the consent to create binding which can be viewed as the user doing > dynamic registration. > https://wiki.idesg.org/wiki/index.php/Consent_to_Create_Binding > > These are IMHO necessary to do distributed identity. > > thx ..Tom (mobile) > > On Mon, Aug 3, 2020, 8:34 AM Justin Richer wrote: > >> Fabien, >> >> Thanks for writing this up, this is interesting work! So if I=E2=80=99m = reading >> this correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is now also u= sed to connect the >> consent component with the AS, right? I like how it folds in the >> verification of components with a really simple calculation, and that >> allows the steps to be chained together. I really like that the extra st= eps >> don=E2=80=99t affect what the client needs to know or what it has to do,= so a >> server could deploy with or without this and not change client behavior. >> >> I have a couple questions about how you think this might play out in a >> deployment: >> >> 1) Do you think the interact server would sign its request to the AS in >> 7? Since it=E2=80=99s a direct HTTP POST this should be able to use any = of the >> signing/proof mechanisms that the rest of GNAP would use. >> 2) How does the interaction server get information about the consent >> being gathered, in order to display the appropriate UI to the user? This >> seems like it could be part of the exchange in 7/8 but I=E2=80=99m not s= ure what >> the details would look like, any thoughts there? >> 3) How does the interaction server communicate the results of the consen= t >> back to the AS? It seems like that would require a second round trip. >> >> >> I=E2=80=99m particularly interested in this idea because it could allow >> standardization of something that OAuth is really bad at: interaction >> through components that are not accessed via web browser. Think of it li= ke >> this: you=E2=80=99ve got an AS that handles the tokens and managing stat= e and all >> that, but you=E2=80=99ve got an on-device app to handle the actual conse= nt and user >> interaction portions. Previously, I=E2=80=99d hand-waved that they=E2=80= =99d talk to each >> other somehow, but this approach could give us a way for that on-device = app >> to talk back to the AS, get the information it needs to draw a UI, and >> continue the request without it needing to have a full view of everythin= g >> back at the server. >> >> =E2=80=94 Justin >> >> On Aug 3, 2020, at 7:15 AM, Fabien Imbault >> wrote: >> >> Hello, >> >> This is a new thread. >> >> I have just published a proof of concept that separates the interaction >> from the rest of the AS. The goal is to open up the door to a privacy >> preserving flow such as the one suggested by Denis (the interaction may = be >> handled by a Client endpoint, if it wishes), as well as to optimize the >> implementation to each concern (UX for consent vs authorization flows). >> >> Note that it ends up being an implementation detail as far as the Client >> is concerned, as the core request/response format wasn't changed from th= e >> original XYZ protocol. >> >> The code and documentation is available publicly at: >> https://github.com/acertio/mvp_gnap_interact >> >> The flow is sketched and explained at >> https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#pro= cess >> >> Let me know what you think. >> >> Cheers >> >> Fabien >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000089024805abfdda22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the references Tom, will definitely check them = out.
Fabien

On Mon, Aug 3, 2020 at 7:30 PM Tom Jones <thomasclinganjones@gmail.com&g= t; wrote:
Here is an alternative to that consisting of t= wo token "niblets", essentially=C2=A0signed and encoded tokens th= at are designed to be embedded in an az token. These can be viewed as lite-= weight VCs.

htt= ps://wiki.idesg.org/wiki/index.php/Delegation

and the consent to= create binding which can be viewed as the user doing dynamic registration.=

These are IMHO necessary to do distributed identity.

thx ..Tom (mobile)

On Mon, Aug 3, 2020, 8:= 34 AM Justin Richer <jricher@mit.edu> wrote:
Fabien,

Thanks = for writing this up, this is interesting work! So if I=E2=80=99m reading th= is correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is now also used t= o connect the consent component with the AS, right? I like how it folds in = the verification of components with a really simple calculation, and that a= llows the steps to be chained together. I really like that the extra steps = don=E2=80=99t affect what the client needs to know or what it has to do, so= a server could deploy with or without this and not change client behavior.= =C2=A0

I have a couple questions about how you thi= nk this might play out in a deployment:

1) Do you = think the interact server would sign its request to the AS in 7? Since it= =E2=80=99s a direct HTTP POST this should be able to use any of the signing= /proof mechanisms that the rest of GNAP would use.
2) How does th= e interaction server get information about the consent being gathered, in o= rder to display the appropriate UI to the user? This seems like it could be= part of the exchange in 7/8 but I=E2=80=99m not sure what the details woul= d look like, any thoughts there?
3) How does the interaction serv= er communicate the results of the consent back to the AS? It seems like tha= t would require a second round trip.


I=E2=80=99m particularly interested in this idea because it could allow s= tandardization of something that OAuth is really bad at: interaction throug= h components that are not accessed via web browser. Think of it like this: = you=E2=80=99ve got an AS that handles the tokens and managing state and all= that, but you=E2=80=99ve got an on-device app to handle the actual consent= and user interaction portions. Previously, I=E2=80=99d hand-waved that the= y=E2=80=99d talk to each other somehow, but this approach could give us a w= ay for that on-device app to talk back to the AS, get the information it ne= eds to draw a UI, and continue the request without it needing to have a ful= l view of everything back at the server.

=C2=A0=E2= =80=94 Justin

On Aug 3, 2020, at= 7:15 AM, Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:

Hello,=C2=A0

T= his is a new thread.=C2=A0

I have just published a= proof of concept that separates the interaction from the rest of the AS. T= he goal is to open up the door to a privacy preserving flow such as the one= suggested by Denis (the interaction may be handled by a Client endpoint, i= f it wishes), as well as to optimize the implementation to each concern (UX= for consent vs authorization flows).=C2=A0

Note t= hat it ends up being an implementation detail as far as the Client is conce= rned, as the core request/response format wasn't changed from the origi= nal XYZ protocol.

The code and documentation is av= ailable publicly at:


Let me know what you think.

Cheers

Fabien
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
<= /blockquote>

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--00000000000089024805abfdda22-- From nobody Mon Aug 3 14:16:40 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 BFF5C3A0D50 for ; Mon, 3 Aug 2020 14:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 0WkYcM10m8KX for ; Mon, 3 Aug 2020 14:16:36 -0700 (PDT) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 A04AC3A0C89 for ; Mon, 3 Aug 2020 14:16:36 -0700 (PDT) Received: by mail-oo1-xc2a.google.com with SMTP id a9so7562165oof.12 for ; Mon, 03 Aug 2020 14:16:36 -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=glnorEcQL51DxjDfcT/k5NwoW+nU/m3AMKZLXsNYyq8=; b=uNs+SKFdECKJmhJqGcAbnm6yZpLXklh/G72RJSfZ65f6NVN5A2wZ7g1tD6+OuTIpd3 mfqqhwZZ83+GNR2Q+m9QU44RMu9UxK+qAR9Nx2zXo2gYMbHqU+21pIOcPO+AqujkWR8C 635OeUBeF6YqMj1Z8oMJmVGsEnbGzT9PniApHO1/40BO0kfRoNBdsGZmABhGJo6/Ojqa cizbYF4FCsj8MbjJuEYAHz6YRrbP5P4Vlw1TGvSXfb+j+zO4XE6utQ3k+Lvt4bo0RSuA t6doIJDKG8ZnopeIj1d8goYFhmp1HSgbQB3yqMkpNqkpHgHw5qxZcnOxg7L3qPqjPv8e u8iw== 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=glnorEcQL51DxjDfcT/k5NwoW+nU/m3AMKZLXsNYyq8=; b=Kg2713M5QqL6XCpaca5gZNBoaudAxFeDWNF46w7uDDF1N4wBjJi2DxqVqz6L2jLNay BxnzRIyOfBbFcd0Yje2/+fb3s/M8F1JKvH2+VUKDBZALE1UhXlExi4/z1TKyYE+RolGv amKpCtGFsNgoAiud+H+5pgfQmL9Iz4X2NBwaZZYe2xeohysByK+kflt78A0FETNKDrc9 xjmU0V/G/uqdsLQc3TGfrVMnm4kvhu34os6bRRpPWcTviQN3nKfxe7NrmzPdcOwokboM /t9NNfn6NKdQVDK8P1i//Y1xkTpcFQJaFPNMZHWx0VtN5E/OmlVA4LM4pXh9rbPci+yi zsAQ== X-Gm-Message-State: AOAM532nyVQS3VP4iFGKLVS/CCLYd09Iv2/7hVKu+nwEMFf7N7hWDbnR wBzG/Uc5dTZaZIxkPoDG5tO6GJUIx2SlrK8eP9M= X-Google-Smtp-Source: ABdhPJzsLQj+0tVSj4+OvMh6HHjeaxVCwT87859+cfWi15/VpobYcLDtYspdA6vWxkjmLn+L/HRPwZSvQXgPxncdTXU= X-Received: by 2002:a4a:3443:: with SMTP id n3mr16093766oof.30.1596489395512; Mon, 03 Aug 2020 14:16:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Mon, 3 Aug 2020 14:16:24 -0700 Message-ID: To: Justin Richer Cc: Denis , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000004ea9d705abffa78a" Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 03 Aug 2020 21:16:39 -0000 --0000000000004ea9d705abffa78a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In our use cases the client and rs are indistinguishable other than one is a source and the other a sink of data. They can reverse roles rapidly. I agree that client is not a helpful name. Peace ..tom On Mon, Aug 3, 2020 at 12:02 PM Justin Richer wrote: > Hi Denis, > > I think there=E2=80=99s still a problem with the terminology in use here.= What you > describe as RS2, which might in fact be an RS unto itself, is a =E2=80=9C= Client=E2=80=9D in > OAuth parlance because it is *a client of RS1*. What you call a =E2=80=9C= client=E2=80=9D > has no analogue in the OAuth world, but it is not at all the same as an > OAuth client. I appreciate your mapping of the entities below, but it mak= es > it difficult to hold a discussion if we aren=E2=80=99t using the same ter= ms. > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we can de= fine our > own terms. The bad news is that this is really hard to do. > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new definit= ions, but > we=E2=80=99ve got a chance to be more precise with how we define things. = This could > mean splitting up things into multiple roles, or defining new roles for > aspects that weren=E2=80=99t in consideration in the protocol previously.= Perhaps > what you=E2=80=99re calling a client below could potentially be considere= d the > =E2=80=9Cinteraction component=E2=80=9D or =E2=80=9Cconsent gatherer=E2= =80=9D, which was previously a > portion of the AS. > > I=E2=80=99ve never been a fan of the term =E2=80=9Cclient=E2=80=9D in OAu= th because it=E2=80=99s too > generic and confusing to a lot of developers, especially the web > programmers that OAuth is aimed at. =E2=80=9CUser Agent=E2=80=9D would be= similarly > unsuitable for the same reasons =E2=80=94 both =E2=80=9Cclient=E2=80=9D a= nd =E2=80=9Cuser agent=E2=80=9D are taken > to mean =E2=80=9Cbrowser=E2=80=9D in many circles. I=E2=80=99d love for u= s to come up with a new > term for this, but apart from the =E2=80=9CResource Client (RC)=E2=80=9D = that I proposed in > the XYZ Draft, I don=E2=80=99t have an answer. > > =E2=80=94 Justin > > On Aug 3, 2020, at 3:35 AM, Denis wrote: > > Hello Dick, > > This is a follow-up of the thread: "Reviewing > draft-hardt-xauth-protocol-11". > > Hereafter are three exchanges between you and me which triggered this new > thread: > > [Dick] The photo sharing example was a driving use case for the > creation of OAuth. > [Denis] We would need to revisit the original scenario and consider if i= t > can be addressed in a different way than the original way. > [Dick] The use case is the same. Is there a different solution you are > proposing ? > > My response is : Yes indeed, I have a different solution to address the > same use case. > > RFC 6749 and draft-ietf-oauth-v2-1-00 both state: > > For example, an end-user (resource owner) can grant a printing service > (client) access to her protected photos stored at > a photo-sharing service (resource server), without sharing her username > and password with the printing service. Instead, > she authenticates directly with a server trusted by the photo-sharing > service (authorization server), which issues the printing > service delegation-specific credentials (access token). > > There are no further explanations. > > Which information will be disclosed by the resource owner to the > authorization server to get "the printing service delegation-specific > credentials" > is not described. It is a private agreement between the AS and the RS. It > is more than likely that the authorization server will learn information > about which operation the resource owner is wishing to perform and where. > Since in OAuth, the access token is supposed to be opaque to the Client, > the user will be unable to make sure that her instructions have been > carefully followed. > > RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do > not contain a "Privacy Considerations" section. > Thus, the leakage of information to the AS is not discussed. > > It is possible to revisit the original scenario by applying "Privacy by > design" principles. > > The scenario can be solved by using an old data transfer method that has > been first described 32 years ago under the name > "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later > in ISO/IEC 10740-2:1993. > > RDT allows two servers to directly exchange large amounts of data under > the supervision of a client by communicating, through the client, > a reference generated by one server to the other server. RDT does not use > any Authorization Server (AS). This means that no AS is able > to act as Big Brother and this solves a major privacy concern. > > > * The three entities involved * > The Client supporting a User (was the Resource Owner). > The Photo-sharing service (was the Resource Server) : RS1. > The Printing service (was the client): RS2. > > > > *Flow of operations with the Photo-sharing service (RS1) *The Client > first connects to the photo-sharing service (RS1) and the User > authenticates to the photo-sharing service (RS1). > > RS1 to User: "Please select the operation to be performed". > Operation selected: "Print pictures using a third party printing service"= . > > RS1 to User: "Please select a set of pictures to be printed". > The User selects the pictures. > > RS 1 User consent: "Do you agree RS1 to communicate your selection of > pictures to a third party printing service" ? > If the User consents, RS1 to Client: "Here is the reference to be used by > your printing service to get the selected pictures". > > * Flow of operations with the Printing service* ( > *RS2) * > The Client connects to the printing service (RS2) and the User > authenticates to the printing service (RS2). > > *Note*: This allows to make sure that the user has an account > on RS2 so that further operations can be charged to this account > and that the prints can be sent to a known address. > > RS2 to User: "Please select the operation to be performed". > Operation : "Print pictures to be received from a photo-sharing service "= . > RS2 to User: "Please indicate your photo-sharing service". > The User responds: RS1. > > "Please enter the reference to be used by RS2 to receive the set of > pictures from RS1". > The Client (or the User) enters the reference generated by RS1. > > RS2 contacts RS1 using that reference in order to get the characteristics > and the thumbnails of the pictures to be printed (i.e. not yet the whole > pictures). > > RS2 to client: What are your printing preferences for each picture (e.g. > number of prints, size, quality of the paper, resolution, margins, colour= s, > etc... ) ? > The User responds to all these questions. > > RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do you a= gree ? > If the payment needs to be done on-line, then a payment phase is inserted= . > > > > * Continuation of the flow of operations *Final message from RS1 to the > Client: "Your selection of pictures will be soon transmitted to RS2". > Final message from RS2 to the Client: "Your prints will be soon on their > way". > > RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to > this reference. > > * Some of the advantages of RDT* > > 1. An end-user can grant a printing service (RS2) access to her > protected photos stored at a photo-sharing service (RS1), > without sharing her username and password with the printing service. > 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves > the Big Brother privacy issue. > 3. Any authentication method supported by RS1 or RS2 can be used by > the User. > 4. The User can use any photo-sharing service (RS1) with any printing > service (RS2), as long as they both support RDT. > 5. The User consent is first performed with the photo-sharing service > (RS1) and then after with the printing service (RS2). > 6. The reference generated by RS1 will only be accepted by RS1 during > a time period. > 7. The reference generated by RS1 allows RS2 to query first the > thumbnails and then after the pictures selected by the User at RS1. > 8. The data transfer of the pictures selected at RS1 by the User is > performed asynchronously from RS1 to RS2 as a back-office operation. > > *Questions*: What would be the full scenario of this use case using OAuth > ? What about Privacy Considerations ? > > Denis > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000004ea9d705abffa78a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In our use cases the client and rs are indistinguishable o= ther than one is a source and the other a sink of data. They can reverse ro= les rapidly. I agree that client is not a helpful name.
Peace ..tom

On Mon, = Aug 3, 2020 at 12:02 PM Justin Richer <jricher@mit.edu> wrote:
Hi Denis,
I think there=E2=80=99s still a problem with the terminology i= n use here. What you describe as RS2, which might in fact be an RS unto its= elf, is a =E2=80=9CClient=E2=80=9D in OAuth parlance because it is a cli= ent of RS1. What you call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analog= ue in the OAuth world, but it is not at all the same as an OAuth client. I = appreciate your mapping of the entities below, but it makes it difficult to= hold a discussion if we aren=E2=80=99t using the same terms.
The good news is that this isn=E2=80=99t OAuth, and as a new WG= we can define our own terms. The bad news is that this is really hard to d= o.

In GNAP, we shouldn=E2=80=99t just re-use exist= ing terms with new definitions, but we=E2=80=99ve got a chance to be more p= recise with how we define things. This could mean splitting up things into = multiple roles, or defining new roles for aspects that weren=E2=80=99t in c= onsideration in the protocol previously. Perhaps what you=E2=80=99re callin= g a client below could potentially be considered the =E2=80=9Cinteraction c= omponent=E2=80=9D or =E2=80=9Cconsent gatherer=E2=80=9D, which was previous= ly a portion of the AS.=C2=A0

I=E2=80=99ve never b= een a fan of the term =E2=80=9Cclient=E2=80=9D in OAuth because it=E2=80=99= s too generic and confusing to a lot of developers, especially the web prog= rammers that OAuth is aimed at. =E2=80=9CUser Agent=E2=80=9D would be simil= arly unsuitable for the same reasons =E2=80=94 both =E2=80=9Cclient=E2=80= =9D and =E2=80=9Cuser agent=E2=80=9D are taken to mean =E2=80=9Cbrowser=E2= =80=9D in many circles. I=E2=80=99d love for us to come up with a new term = for this, but apart from the =E2=80=9CResource Client (RC)=E2=80=9D that I = proposed in the XYZ Draft, I don=E2=80=99t have an answer.

=C2=A0=E2=80=94 Justin

= On Aug 3, 2020, at 3:35 AM, Denis <denis.ietf@free.fr> wrote:

=20

Hello Dick,


This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]=C2=A0=C2=A0=C2=A0 The photo sharing example was a driving = use case for the creation of OAuth.
[Denis]=C2=A0 We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]=C2=A0=C2=A0 The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printin= g service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed.=C2=A0

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a= few years later in IS= O/IEC 10740-2:1993.=

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed&qu= ot;.
Operation selected: "Print pictures using a third party printi= ng service".

RS1 to User: "Please select a set of pictures to be printed&qu= ot;.
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and that the p= rints can be sent to a known address.

RS2 to User: "Please select the operation to be performed"= ;.
Operation : "Print pictures to be received from a photo-sharin= g service ".
RS2 to User: "Please indicate your photo-sharing service"= .
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the s= et of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do= you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor= RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authenticati= on method supported by RS1 or RS2 can be used by the User.
  4. The User can use= any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent= is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference ge= nerated by RS1 will only be accepted by RS1 during a time period.
  7. The reference ge= nerated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfe= r of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.=

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis

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

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000004ea9d705abffa78a-- From nobody Tue Aug 4 02:07:55 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 D95AE3A101C for ; Tue, 4 Aug 2020 02:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.212 X-Spam-Level: ** X-Spam-Status: No, score=2.212 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no autolearn_force=no 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 PqSkpPiYvy0s for ; Tue, 4 Aug 2020 02:07:53 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A333A0C9D for ; Tue, 4 Aug 2020 02:07:53 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d64 with ME id BM7q230032bcEcA03M7qZi; Tue, 04 Aug 2020 11:07:51 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 04 Aug 2020 11:07:51 +0200 X-ME-IP: 90.79.51.120 To: "txauth@ietf.org" From: Denis Message-ID: Date: Tue, 4 Aug 2020 11:07:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CF5687C134A8390CA70426A6" Content-Language: en-GB Archived-At: Subject: [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 04 Aug 2020 09:07:55 -0000 This is a multi-part message in MIME format. --------------CF5687C134A8390CA70426A6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I tried my best twice to download three use cases in the Use cases directory, but I failed. Rather than failing a third time, here is the direct link of the second try: https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) Denis --------------CF5687C134A8390CA70426A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--------------CF5687C134A8390CA70426A6-- From nobody Tue Aug 4 02:28:12 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 8C07D3A0BE9 for ; Tue, 4 Aug 2020 02:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 roNsobwwujFS for ; Tue, 4 Aug 2020 02:28:07 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695413A0CA7 for ; Tue, 4 Aug 2020 02:28:06 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d64 with ME id BMU4230042bcEcA03MU4Yv; Tue, 04 Aug 2020 11:28:04 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 04 Aug 2020 11:28:04 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: From: Denis Message-ID: <722214c8-59f6-ec8e-f4d1-f77682cceb52@free.fr> Date: Tue, 4 Aug 2020 11:28:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D261EB99C977F2A555DF457E" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 09:28:10 -0000 This is a multi-part message in MIME format. --------------D261EB99C977F2A555DF457E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > Hi Denis > > In your proposed flow, how does RS2 know who the user is that it is > dealing with? The response is in the text: "The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)". > In OAuth, the AS authenticates the User for the RS. In the photo > sharing example, the AS and RS are from the same organization, so the > AS knowing what the RS was doing was not an issue. Nevertheless, a full description is still missing and might help to better understand the privacy issues. > What you call a Client is not an OAuth Client, but is more of an agent > for the User. RFC 6749 states: In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. This is how I use the term client which fits with the Client-Server model. However, RFC 6749 also states in section 1.1 (Roles) : client       An application making protected resource requests on behalf of the resource owner and with its authorization. This is clearly not how I use the term client. The term "User Agent" might grasp the concept, but I clearly like better the term "Client", as long as we define the use of this term in the context of GNAP. Denis > Microsoft InfoCards comes to mind as a comparable architecture, and it > seems aligned with what Tom is asking for. > > > > > > On Mon, Aug 3, 2020 at 12:35 AM Denis > wrote: > > Hello Dick, > > This is a follow-up of the thread: "Reviewing > draft-hardt-xauth-protocol-11". > > Hereafter are three exchanges between you and me which triggered > this new thread: > > [Dick]    The photo sharing example was a driving use case for > the creation of OAuth. > [Denis]  We would need to revisit the original scenario and > consider if it can be addressed in a different way than the > original way. > [Dick]   The use case is the same. Is there a different > solution you are proposing ? > > My response is : Yes indeed, I have a different solution to > address the same use case. > > RFC 6749 and draft-ietf-oauth-v2-1-00 both state: > > For example, an end-user (resource owner) can grant a printing > service (client) access to her protected photos stored at > a photo-sharing service (resource server), without sharing her > username and password with the printing service. Instead, > she authenticates directly with a server trusted by the > photo-sharing service (authorization server), which issues the > printing > service delegation-specific credentials (access token). > > There are no further explanations. > > Which information will be disclosed by the resource owner to the > authorization server to get "the printing service > delegation-specific credentials" > is not described. It is a private agreement between the AS and the > RS. It is more than likely that the authorization server will > learn information > about which operation the resource owner is wishing to perform and > where. Since in OAuth, the access token is supposed to be opaque > to the Client, > the user will be unable to make sure that her instructions have > been carefully followed. > > RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: > they do not contain a "Privacy Considerations" section. > Thus, the leakage of information to the AS is not discussed. > > It is possible to revisit the original scenario by applying > "Privacy by design" principles. > > The scenario can be solved by using an old data transfer method > that has been first described 32 years ago under the name > "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few > years later in ISO/IEC 10740-2:1993. > > RDT allows two servers to directly exchange large amounts of data > under the supervision of a client by communicating, through the > client, > a reference generated by one server to the other server. RDT does > not use any Authorization Server (AS). This means that no AS is able > to act as Big Brother and this solves a major privacy concern. > * > The three entities involved > * > The Client supporting a User (was the Resource Owner). > The Photo-sharing service (was the Resource Server) : RS1. > The Printing service (was the client): RS2. > * > * > > *Flow of operations with the Photo-sharing service (RS1) > > *The Client first connects to the photo-sharing service (RS1) and > the User authenticates to the photo-sharing service (RS1). > > RS1 to User: "Please select the operation to be performed". > Operation selected: "Print pictures using a third party printing > service". > > RS1 to User: "Please select a set of pictures to be printed". > The User selects the pictures. > > RS 1 User consent: "Do you agree RS1 to communicate your selection > of pictures to a third party printing service" ? > If the User consents, RS1 to Client: "Here is the reference to be > used by your printing service to get the selected pictures". > * > Flow of operations with the Printing service* (*RS2) > * > The Client connects to the printing service (RS2) and the User > authenticates to the printing service (RS2). > > _Note_: This allows to make sure that the user has an account on > RS2 so that further operations can be charged to this account >                       and that the prints can be sent to a known > address. > > RS2 to User: "Please select the operation to be performed". > Operation : "Print pictures to be received from a photo-sharing > service ". > RS2 to User: "Please indicate your photo-sharing service". > The User responds: RS1. > > "Please enter the reference to be used by RS2 to receive the set > of pictures from RS1". > The Client (or the User) enters the reference generated by RS1. > > RS2 contacts RS1 using that reference in order to get the > characteristics and the thumbnails of the pictures to be printed > (i.e. not yet the whole pictures). > > RS2 to client: What are your printing preferences for each picture > (e.g. number of prints, size, quality of the paper, resolution, > margins, colours, etc... ) ? > The User responds to all these questions. > > RS 2 User consent: This operation will be charged XX € ? Do you > agree ? > If the payment needs to be done on-line, then a payment phase is > inserted. > * > Continuation of the flow of operations > > *Final message from RS1 to the Client: "Your selection of pictures > will be soon transmitted to RS2". > Final message from RS2 to the Client: "Your prints will be soon on > their way". > > RS2 to RS1 (asynchronous): transmit the set of pictures > corresponding to this reference. > * > Some of the advantages of RDT* > > 1. An end-user can grant a printing service (RS2) access to her > protected photos stored at a photo-sharing service (RS1), > without sharing her username and password with the printing > service. > 2. Neither RS1, nor RS2 need to use or to trust any AS. This > solves the Big Brother privacy issue. > 3. Any authentication method supported by RS1 or RS2 can be used > by the User. > 4. The User can use any photo-sharing service (RS1) with any > printing service (RS2), as long as they both support RDT. > 5. The User consent is first performed with the photo-sharing > service (RS1) and then after with the printing service (RS2). > 6. The reference generated by RS1 will only be accepted by RS1 > during a time period. > 7. The reference generated by RS1 allows RS2 to query first the > thumbnails and then after the pictures selected by the User at > RS1. > 8. The data transfer of the pictures selected at RS1 by the User > is performed asynchronously from RS1 to RS2 as a back-office > operation. > > *Questions*: What would be the full scenario of this use case > using OAuth ? What about Privacy Considerations ? > > Denis > --------------D261EB99C977F2A555DF457E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Dick,

Hi Denis

In your proposed flow, how does RS2 know who the user is that it is dealing with?

The response is in the text: "The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)".

In OAuth, the AS authenticates the User for the RS. In the photo sharing example, the AS and RS are from the same organization, so the AS knowing what the RS was doing was not an issue.

Nevertheless, a full description is still missing and might help to better understand the privacy issues.

What you call a Client is not an OAuth Client, but is more of an agent for the User.

RFC 6749 states:

In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server,
and is issued a different set of credentials than those of the resource owner.

This is how I use the term client which fits with the Client-Server model.

However, RFC 6749 also states in section 1.1 (Roles) :

client
      An application making protected resource requests on behalf of the resource owner and with its authorization.

This is clearly not how I use the term client.

The term "User Agent" might grasp the concept, but I clearly like better the term "Client",
as long as we define the use of this term in the context of GNAP.

Denis

Microsoft InfoCards comes to mind as a comparable architecture, and it seems aligned with what Tom is asking for.





On Mon, Aug 3, 2020 at 12:35 AM Denis <denis.ietf@free.fr> wrote:

Hello Dick,

This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]    The photo sharing example was a driving use case for the creation of OAuth.
[Denis]  We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]   The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed. 

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

            Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
                      and that the prints can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX € ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis


--------------D261EB99C977F2A555DF457E-- From nobody Tue Aug 4 02:31:42 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 331563A0CA7 for ; Tue, 4 Aug 2020 02:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2SF0fKvXN9Zm for ; Tue, 4 Aug 2020 02:31:37 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9D33A0C13 for ; Tue, 4 Aug 2020 02:31:36 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d64 with ME id BMXa2300A2bcEcA03MXbHc; Tue, 04 Aug 2020 11:31:35 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 04 Aug 2020 11:31:35 +0200 X-ME-IP: 90.79.51.120 To: Justin Richer Cc: "txauth@ietf.org" References: From: Denis Message-ID: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> Date: Tue, 4 Aug 2020 11:31:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6617F29754A354476A9FF77E" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 09:31:40 -0000 This is a multi-part message in MIME format. --------------6617F29754A354476A9FF77E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, Since you replied in parallel, I will make a response similar to the one I sent to Dick. > Hi Denis, > > I think there’s still a problem with the terminology in use here. What > you describe as RS2, which might in fact be an RS unto itself, is a > “Client” in OAuth parlance because it is /a client of RS1/. What you > call a “client” has no analogue in the OAuth world, but it is not at > all the same as an OAuth client. I appreciate your mapping of the > entities below, but it makes it difficult to hold a discussion if we > aren’t using the same terms. > > The good news is that this isn’t OAuth, and as a new WG we can define > our own terms. The bad news is that this is really hard to do. > > In GNAP, we shouldn’t just re-use existing terms with new definitions, > but we’ve got a chance to be more precise with how we define things. In the ISO context, each document must define its own terminology. The boiler plate for RFCs does not mandate a terminology or definitions section but does not prevent it either. The vocabulary is limited and as long as we clearly define what our terms are meaning, we can re-use a term already used in another RFC. This is also the ISO approach. > This could mean splitting up things into multiple roles, or defining > new roles for aspects that weren’t in consideration in the protocol > previously. > Perhaps what you’re calling a client below could potentially be > considered the “interaction component” or “consent gatherer”, which > was previously a portion of the AS. > > I’ve never been a fan of the term “client” in OAuth because it’s too > generic and confusing to a lot of developers, especially the web > programmers that OAuth is aimed at. If the term “client” in OAuth should be understood as defined in in section 1.1 (Roles) from RFC 6749, i.e.: client : An application making protected resource requests on behalf of the resource owner and with its authorization. then this term is clearly not compatible with the term client from the Client-Server model. > “User Agent” would be similarly unsuitable for the same reasons — both > “client” and “user agent” are taken to mean “browser” in many circles. Maybe, but it is not my understanding. > I’d love for us to come up with a new term for this, but apart from > the “Resource Client (RC)” that I proposed in the XYZ Draft, I don’t > have an answer. By best answer is to use the term Client for what it means in the context of a Client-Server model. Hereafter are two ISO definitions: client : entity that requests a service from a server (ISO/IEC 14776-414:2009, 3.1.16) client application: software application that accesses a remote service usually on another computer system (ISO 24619:2011, 3.3.5) Denis > >  — Justin > >> On Aug 3, 2020, at 3:35 AM, Denis > > wrote: >> >> Hello Dick, >> >> >> This is a follow-up of the thread: "Reviewing >> draft-hardt-xauth-protocol-11". >> >> Hereafter are three exchanges between you and me which triggered this >> new thread: >> >> [Dick]    The photo sharing example was a driving use case for >> the creation of OAuth. >> [Denis]  We would need to revisit the original scenario and >> consider if it can be addressed in a different way than the >> original way. >> [Dick]   The use case is the same. Is there a different solution >> you are proposing ? >> >> My response is : Yes indeed, I have a different solution to address >> the same use case. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >> >> For example, an end-user (resource owner) can grant a printing >> service (client) access to her protected photos stored at >> a photo-sharing service (resource server), without sharing her >> username and password with the printing service. Instead, >> she authenticates directly with a server trusted by the >> photo-sharing service (authorization server), which issues the >> printing >> service delegation-specific credentials (access token). >> >> There are no further explanations. >> >> Which information will be disclosed by the resource owner to the >> authorization server to get "the printing service delegation-specific >> credentials" >> is not described. It is a private agreement between the AS and the >> RS. It is more than likely that the authorization server will learn >> information >> about which operation the resource owner is wishing to perform and >> where. Since in OAuth, the access token is supposed to be opaque to >> the Client, >> the user will be unable to make sure that her instructions have been >> carefully followed. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they >> do not contain a "Privacy Considerations" section. >> Thus, the leakage of information to the AS is not discussed. >> >> It is possible to revisit the original scenario by applying "Privacy >> by design" principles. >> >> The scenario can be solved by using an old data transfer method that >> has been first described 32 years ago under the name >> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years >> later in ISO/IEC 10740-2:1993. >> >> RDT allows two servers to directly exchange large amounts of data >> under the supervision of a client by communicating, through the client, >> a reference generated by one server to the other server. RDT does not >> use any Authorization Server (AS). This means that no AS is able >> to act as Big Brother and this solves a major privacy concern. >> * >> The three entities involved >> * >> The Client supporting a User (was the Resource Owner). >> The Photo-sharing service (was the Resource Server) : RS1. >> The Printing service (was the client): RS2. >> * >> * >> >> *Flow of operations with the Photo-sharing service (RS1) >> >> *The Client first connects to the photo-sharing service (RS1) and the >> User authenticates to the photo-sharing service (RS1). >> >> RS1 to User: "Please select the operation to be performed". >> Operation selected: "Print pictures using a third party printing >> service". >> >> RS1 to User: "Please select a set of pictures to be printed". >> The User selects the pictures. >> >> RS 1 User consent: "Do you agree RS1 to communicate your selection of >> pictures to a third party printing service" ? >> If the User consents, RS1 to Client: "Here is the reference to be >> used by your printing service to get the selected pictures". >> * >> Flow of operations with the Printing service* (*RS2) >> * >> The Client connects to the printing service (RS2) and the User >> authenticates to the printing service (RS2). >> >> _Note_: This allows to make sure that the user has an account on RS2 >> so that further operations can be charged to this account >>                       and that the prints can be sent to a known address. >> >> RS2 to User: "Please select the operation to be performed". >> Operation : "Print pictures to be received from a photo-sharing >> service ". >> RS2 to User: "Please indicate your photo-sharing service". >> The User responds: RS1. >> >> "Please enter the reference to be used by RS2 to receive the set of >> pictures from RS1". >> The Client (or the User) enters the reference generated by RS1. >> >> RS2 contacts RS1 using that reference in order to get the >> characteristics and the thumbnails of the pictures to be printed >> (i.e. not yet the whole pictures). >> >> RS2 to client: What are your printing preferences for each picture >> (e.g. number of prints, size, quality of the paper, resolution, >> margins, colours, etc... ) ? >> The User responds to all these questions. >> >> RS 2 User consent: This operation will be charged XX € ? Do you agree ? >> If the payment needs to be done on-line, then a payment phase is >> inserted. >> * >> Continuation of the flow of operations >> >> *Final message from RS1 to the Client: "Your selection of pictures >> will be soon transmitted to RS2". >> Final message from RS2 to the Client: "Your prints will be soon on >> their way". >> >> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding >> to this reference. >> * >> Some of the advantages of RDT* >> >> 1. An end-user can grant a printing service (RS2) access to her >> protected photos stored at a photo-sharing service (RS1), >> without sharing her username and password with the printing service. >> 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves >> the Big Brother privacy issue. >> 3. Any authentication method supported by RS1 or RS2 can be used by >> the User. >> 4. The User can use any photo-sharing service (RS1) with any >> printing service (RS2), as long as they both support RDT. >> 5. The User consent is first performed with the photo-sharing >> service (RS1) and then after with the printing service (RS2). >> 6. The reference generated by RS1 will only be accepted by RS1 >> during a time period. >> 7. The reference generated by RS1 allows RS2 to query first the >> thumbnails and then after the pictures selected by the User at RS1. >> 8. The data transfer of the pictures selected at RS1 by the User is >> performed asynchronously from RS1 to RS2 as a back-office operation. >> >> *Questions*: What would be the full scenario of this use case using >> OAuth ? What about Privacy Considerations ? >> >> Denis >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --------------6617F29754A354476A9FF77E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Justin,

Since you replied in parallel, I will make a response similar to the one I sent to Dick.

Hi Denis,

I think there’s still a problem with the terminology in use here. What you describe as RS2, which might in fact be an RS unto itself, is a “Client” in OAuth parlance because it is a client of RS1. What you call a “client” has no analogue in the OAuth world, but it is not at all the same as an OAuth client. I appreciate your mapping of the entities below, but it makes it difficult to hold a discussion if we aren’t using the same terms.

The good news is that this isn’t OAuth, and as a new WG we can define our own terms. The bad news is that this is really hard to do.

In GNAP, we shouldn’t just re-use existing terms with new definitions, but we’ve got a chance to be more precise with how we define things.

In the ISO context, each document must define its own terminology. The boiler plate for RFCs does not mandate a terminology or definitions section
but does not prevent it either. The vocabulary is limited and as long as we clearly define what our terms are meaning, we can re-use a term already
used in another RFC. This is also the ISO approach.

This could mean splitting up things into multiple roles, or defining new roles for aspects that weren’t in consideration in the protocol previously.
Perhaps what you’re calling a client below could potentially be considered the “interaction component” or “consent gatherer”, which was previously a portion of the AS. 

I’ve never been a fan of the term “client” in OAuth because it’s too generic and confusing to a lot of developers, especially the web programmers that OAuth is aimed at.

If the term “client” in OAuth should be understood as defined in in section 1.1 (Roles) from RFC 6749, i.e.:

client : An application making protected resource requests on behalf of the resource owner and with its authorization.

then this term is clearly not compatible with the term client from the Client-Server model. 

“User Agent” would be similarly unsuitable for the same reasons — both “client” and “user agent” are taken to mean “browser” in many circles.

Maybe, but it is not my understanding.

I’d love for us to come up with a new term for this, but apart from the “Resource Client (RC)” that I proposed in the XYZ Draft, I don’t have an answer.

By best answer is to use the term Client for what it means in the context of a Client-Server model.

Hereafter are two ISO definitions:

client : entity that requests a service from a server (ISO/IEC 14776-414:2009, 3.1.16)

client application: software application that accesses a remote service usually on another computer system (ISO 24619:2011, 3.3.5)

Denis


 — Justin

On Aug 3, 2020, at 3:35 AM, Denis <denis.ietf@free.fr> wrote:

Hello Dick,


This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]    The photo sharing example was a driving use case for the creation of OAuth.
[Denis]  We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]   The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed. 

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

            Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
                      and that the prints can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX € ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis

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


--------------6617F29754A354476A9FF77E-- From nobody Tue Aug 4 05:23:31 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 59D143A0A96 for ; Tue, 4 Aug 2020 05:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 5F8KBn-ZcBur for ; Tue, 4 Aug 2020 05:23:28 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4AC7A3A0A93 for ; Tue, 4 Aug 2020 05:23:28 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id g19so29880796ioh.8 for ; Tue, 04 Aug 2020 05:23:28 -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=fwKqKFa3zLCQCzfZqc2xqvhtZma25e5NJtFZDJdRtM4=; b=npw677c+qFkQ97T+0GTcJembE0UsGYBTs1Vaqu1I3D33rRAYDkJFH0N3sgddpEPN35 y0UTRGai3xecHa+PrVUcPGeoxPga+I1tq9DAXJIQah2sy85wkuHDz+Zmn2GzRKg1pKJl MYum94s0SWmiiYN2BawCuJaBI8xZx0fCHTWih49PWMrE6HW+0SFBhN38HICq2SJZYcP2 UydQrAeR/ydwwU938DcLVhnaivJg8qKmwDXjqJESyfvx9WVpEMZ74m/yVIOW2Snoyc57 hjHsGjayLviPAAG+r+JApShIMC7MKIEUC9u+BAJej6G6yY1vTAw+8yzE/ShZcndl8q3+ jpVw== 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=fwKqKFa3zLCQCzfZqc2xqvhtZma25e5NJtFZDJdRtM4=; b=Fnf5qIX/78aUPQOSoke+oPFoud7BzAUzblsoNR+fqlzmf3SCGCqlkApdzj3oODI5SL pC9PguzE3+RyaoyEzXbaQSGNlhTxT9g+RfV6F/65lE5t3n/ub9N/8RwO78RSbpAB0LaE 6OUuhWUNHEYNzfxqcfWVqbdZF/Qaz+ySAmdr8JZxMyiLN8B2Q+pLDfvyNyS4hiuIlPi2 QlA5SLVrn646vC9ClRgj/RJk9vPJIBS++YPMGJUJdO+0NgT3AFgC2KgzZaaWDlDa9EE3 SboSZz9E70sHAaXvwrqbKDtSnQbDPo/RnZrKCKCJh/Vx/Rr9cLOqhn3RK/pPc975MKJv 2Hyw== X-Gm-Message-State: AOAM5309SFCDCJQQD4GvibYjp9eOaYyslNhJ5RAmhKRAGlfdPRK+rIre KWB8H2rD+gcZeoYJKNyiJYVSqfaC6wjCJ3lxIKscm2zi X-Google-Smtp-Source: ABdhPJxlDO/s8NRN4SlwnQVNhBOBxLtszYJcNuvjvsUMsOUlvzBBH3E2t7a3cUNstqFr8W1bO9GUYELQANVU4Jagtes= X-Received: by 2002:a5d:841a:: with SMTP id i26mr4862125ion.144.1596543807541; Tue, 04 Aug 2020 05:23:27 -0700 (PDT) MIME-Version: 1.0 References: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> <085908D8-8D48-4BE5-818A-B5F1232950BA@mit.edu> In-Reply-To: <085908D8-8D48-4BE5-818A-B5F1232950BA@mit.edu> From: Fabien Imbault Date: Tue, 4 Aug 2020 14:23:15 +0200 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000008454f005ac0c523c" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 04 Aug 2020 12:23:30 -0000 --0000000000008454f005ac0c523c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Justin. I have written a use case for that. Cheers Fabien On Mon, Aug 3, 2020 at 8:27 PM Justin Richer wrote: > Thank you for the clarifications! Yes, I agree that with these > simplifications the protocol collapses quite nicely like this. I wonder i= f > this could be an area where GNAP could provide support for those that nee= d > the extra connections but stay out of the way of those that don=E2=80=99t= =E2=80=94 like > how token introspection allows a runtime query of a token=E2=80=99s statu= s and > capabilities, but nobody=E2=80=99s suggesting it be mandated for all syst= ems (for > what I hope are obvious reasons!). Then perhaps just like introspection > this could be an =E2=80=9Cinternal protocol=E2=80=9D that interested AS= =E2=80=99s would use, but > whether or not it got used wouldn=E2=80=99t affect the outside of the pro= tocol. > This kind of functional layering is a really good design goal. > > Another thing, this makes me wonder if we should in fact split up the rol= e > of what=E2=80=99s classically been the AS into two functional roles. One = part talks > to the client, the other part interacts with the user (interaction > server?). The connection between these components is what this =E2=80=9Ci= nternal > protocol=E2=80=9D would define, though there would be other ways to handl= e it if > you wanted to, just like with introspection. > > If you haven=E2=80=99t done so yet, I would recommend that you write up s= ome pages > in the Use Cases wiki describing the kinds of things you=E2=80=99re after= : > > https://github.com/ietf-wg-gnap/general/wiki/Use-Cases > > =E2=80=94 Justin > > On Aug 3, 2020, at 12:22 PM, Fabien Imbault > wrote: > > Hi Justin, > > Thanks for your feedback. The point is indeed to evaluate whether this > opens up new capabilities. > > A preliminary response: > > 1) yes, we would have to sign the request, by any mean supported by GNAP. > 2) right now it's pretty much hardcoded, which would be fine in some > cases; but more generally the way that requirement is gathered into GNAP > still needs to be worked out: probably the Client needs to do a first cal= l > to the RS before. This is important to know if we want to keep it as an > implementation detail, that the Client may not even care about. Could be > part of the request (the simplest, but is it fine with privacy requiremen= t > if we need to route through the AS?) or we could have continuation Tx > specific to the consent component. > 3) we have a very basic example (global yes/no) in which we didn't have t= o > care (the flow either continues or stops), but indeed, we would need a > second complete HTTP roundtrip (in a simple implementation) or allow more > advanced communication patterns to reduce roundtrips (we have more > flexibility since the Client in not in the loop here). There's currently = a > lot of work on 0-RTT in workgroups such as DIDComm and QUIC that we could > leverage for some high perf scenarios. > > I'll work on a more advanced proposal for these, still a lot of work in > order to keep things simple and stupid ;-) > > Cheers > > Fabien > > On Mon, Aug 3, 2020 at 5:33 PM Justin Richer wrote: > >> Fabien, >> >> Thanks for writing this up, this is interesting work! So if I=E2=80=99m = reading >> this correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is now also u= sed to connect the >> consent component with the AS, right? I like how it folds in the >> verification of components with a really simple calculation, and that >> allows the steps to be chained together. I really like that the extra st= eps >> don=E2=80=99t affect what the client needs to know or what it has to do,= so a >> server could deploy with or without this and not change client behavior. >> >> I have a couple questions about how you think this might play out in a >> deployment: >> >> 1) Do you think the interact server would sign its request to the AS in >> 7? Since it=E2=80=99s a direct HTTP POST this should be able to use any = of the >> signing/proof mechanisms that the rest of GNAP would use. >> 2) How does the interaction server get information about the consent >> being gathered, in order to display the appropriate UI to the user? This >> seems like it could be part of the exchange in 7/8 but I=E2=80=99m not s= ure what >> the details would look like, any thoughts there? >> 3) How does the interaction server communicate the results of the consen= t >> back to the AS? It seems like that would require a second round trip. >> >> >> I=E2=80=99m particularly interested in this idea because it could allow >> standardization of something that OAuth is really bad at: interaction >> through components that are not accessed via web browser. Think of it li= ke >> this: you=E2=80=99ve got an AS that handles the tokens and managing stat= e and all >> that, but you=E2=80=99ve got an on-device app to handle the actual conse= nt and user >> interaction portions. Previously, I=E2=80=99d hand-waved that they=E2=80= =99d talk to each >> other somehow, but this approach could give us a way for that on-device = app >> to talk back to the AS, get the information it needs to draw a UI, and >> continue the request without it needing to have a full view of everythin= g >> back at the server. >> >> =E2=80=94 Justin >> >> On Aug 3, 2020, at 7:15 AM, Fabien Imbault >> wrote: >> >> Hello, >> >> This is a new thread. >> >> I have just published a proof of concept that separates the interaction >> from the rest of the AS. The goal is to open up the door to a privacy >> preserving flow such as the one suggested by Denis (the interaction may = be >> handled by a Client endpoint, if it wishes), as well as to optimize the >> implementation to each concern (UX for consent vs authorization flows). >> >> Note that it ends up being an implementation detail as far as the Client >> is concerned, as the core request/response format wasn't changed from th= e >> original XYZ protocol. >> >> The code and documentation is available publicly at: >> https://github.com/acertio/mvp_gnap_interact >> >> The flow is sketched and explained at >> https://github.com/acertio/mvp_gnap_interact/blob/master/Redirect.md#pro= cess >> >> Let me know what you think. >> >> Cheers >> >> Fabien >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> > --0000000000008454f005ac0c523c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Justin. I have written a use case for that.
Cheers

Fabien

On Mon, Aug 3, 2020= at 8:27 PM Justin Richer <jricher@mi= t.edu> wrote:
Thank you for the clarificat= ions! Yes, I agree that with these simplifications the protocol collapses q= uite nicely like this. I wonder if this could be an area where GNAP could p= rovide support for those that need the extra connections but stay out of th= e way of those that don=E2=80=99t =E2=80=94 like how token introspection al= lows a runtime query of a token=E2=80=99s status and capabilities, but nobo= dy=E2=80=99s suggesting it be mandated for all systems (for what I hope are= obvious reasons!). Then perhaps just like introspection this could be an = =E2=80=9Cinternal protocol=E2=80=9D that interested AS=E2=80=99s would use,= but whether or not it got used wouldn=E2=80=99t affect the outside of the = protocol. This kind of functional layering is a really good design goal.
Another thing, this makes me wonder if we should in fact s= plit up the role of what=E2=80=99s classically been the AS into two functio= nal roles. One part talks to the client, the other part interacts with the = user (interaction server?). The connection between these components is what= this =E2=80=9Cinternal protocol=E2=80=9D would define, though there would = be other ways to handle it if you wanted to, just like with introspection.<= /div>

If you haven=E2=80=99t done so yet, I would recomm= end that you write up some pages in the Use Cases wiki describing the kinds= of things you=E2=80=99re after:


=C2=A0=E2=80=94 Justin

On Aug = 3, 2020, at 12:22 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Justin,=C2=A0

Thanks for your= feedback. The point is indeed to evaluate whether this opens up new capabi= lities.

A preliminary response:=C2=A0
1) yes, we would have to sign the request, by any mean support= ed by GNAP.=C2=A0
2) right now it's pretty much hardcoded, wh= ich would be fine in some cases; but more generally the way that requiremen= t is gathered into GNAP still needs to be worked out: probably the Client n= eeds to do a first call to the RS before. This is important to know if we w= ant to keep it as an implementation detail, that the Client may not even ca= re about. Could be part of the request (the simplest, but is it fine with p= rivacy requirement if we need to route through the AS?) or we could have co= ntinuation Tx specific to the consent component.=C2=A0
3) we have= a very basic example (global yes/no) in which we didn't have to care (= the flow either continues or stops), but indeed, we would need a second com= plete HTTP roundtrip (in a simple implementation) or allow more advanced co= mmunication patterns to reduce roundtrips (we have more flexibility since t= he Client in not in the loop here). There's currently a lot of work on = 0-RTT in workgroups such as DIDComm and QUIC that we could leverage for som= e high perf scenarios.=C2=A0=C2=A0

I'll work o= n a more advanced proposal for these, still a lot of work in order to keep = things simple and stupid ;-)

Cheers

=
Fabien

On Mon, Aug 3, 2020 at 5:33 PM Justin Richer <jricher@mit.edu> w= rote:
Fabie= n,

Thanks for writing this up, this is interesting work!= So if I=E2=80=99m reading this correctly, the =E2=80=9Cinteract_ref=E2=80= =9D portion is now also used to connect the consent component with the AS, = right? I like how it folds in the verification of components with a really = simple calculation, and that allows the steps to be chained together. I rea= lly like that the extra steps don=E2=80=99t affect what the client needs to= know or what it has to do, so a server could deploy with or without this a= nd not change client behavior.=C2=A0

I have a coup= le questions about how you think this might play out in a deployment:
=

1) Do you think the interact server would sign its requ= est to the AS in 7? Since it=E2=80=99s a direct HTTP POST this should be ab= le to use any of the signing/proof mechanisms that the rest of GNAP would u= se.
2) How does the interaction server get information about the = consent being gathered, in order to display the appropriate UI to the user?= This seems like it could be part of the exchange in 7/8 but I=E2=80=99m no= t sure what the details would look like, any thoughts there?
3) H= ow does the interaction server communicate the results of the consent back = to the AS? It seems like that would require a second round trip.
=

I=E2=80=99m particularly interested in this i= dea because it could allow standardization of something that OAuth is reall= y bad at: interaction through components that are not accessed via web brow= ser. Think of it like this: you=E2=80=99ve got an AS that handles the token= s and managing state and all that, but you=E2=80=99ve got an on-device app = to handle the actual consent and user interaction portions. Previously, I= =E2=80=99d hand-waved that they=E2=80=99d talk to each other somehow, but t= his approach could give us a way for that on-device app to talk back to the= AS, get the information it needs to draw a UI, and continue the request wi= thout it needing to have a full view of everything back at the server.

=C2=A0=E2=80=94 Justin

On Aug 3, 2020, at 7:15 AM, Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:

Hello,=C2=A0

T= his is a new thread.=C2=A0

I have just published a= proof of concept that separates the interaction from the rest of the AS. T= he goal is to open up the door to a privacy preserving flow such as the one= suggested by Denis (the interaction may be handled by a Client endpoint, i= f it wishes), as well as to optimize the implementation to each concern (UX= for consent vs authorization flows).=C2=A0

Note t= hat it ends up being an implementation detail as far as the Client is conce= rned, as the core request/response format wasn't changed from the origi= nal XYZ protocol.

The code and documentation is av= ailable publicly at:

The flow is sketched and explained at=C2=A0https://github.com/acertio/mvp_gnap_interact/= blob/master/Redirect.md#process

Let me know wh= at you think.

Cheers

Fabi= en

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


--0000000000008454f005ac0c523c-- From nobody Tue Aug 4 05:29:19 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 ADEE63A0A9B for ; Tue, 4 Aug 2020 05:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.377 X-Spam-Level: * X-Spam-Status: No, score=1.377 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 QB1XX3wku-VZ for ; Tue, 4 Aug 2020 05:29:16 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 52DEF3A0475 for ; Tue, 4 Aug 2020 05:29:16 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id k20so2716221wmi.5 for ; Tue, 04 Aug 2020 05:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=clP2XL80jT6hemIIr4xCIkjiKb7Y3huBg2Wq5EfVjGA=; b=E7nJOaSU/aPsZ62U7f6lRe9N0WcvX9zRyCCv++7z/8e+u3yzkpb/bONeFD+pg+yiGY /zMY5cCRgfBgd9EP64/zUp7tn4xYxSIy/cDb62p8wRJCnJjQVRZWvr+sZr9Kn1eIwfUE gRRH+PIFCtZbEH06cn8yO6LNodtfZT/0vGfb0e+tMXIQDdo/h69tzV0WYhsDIl94n+T6 iaMMYKrhNGudBh4n1no1Bm+4pg0XO6fK5JwtgtNlgqn0IK8esWL9xjbxzN4+MjSQg4s6 CJFvmbZ6TFg5w9oDp5eJtaIEOXIufxofvrxmINk3vBSRkwLy15b8cI7l1tvTc+wg5+yo HD2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=clP2XL80jT6hemIIr4xCIkjiKb7Y3huBg2Wq5EfVjGA=; b=J3J0lYxwuQWHOeaIaaiIRI6IQQ0Qc8VFESiW8LRjLlWkiQ7mwdsMWan+t9vniajJAX fU93C16VkuEgvyZzrsQfjodwI58W6NAhxExOuSW8qPh/KNxzCSDIBtYVgbeQNkq+oPIf DWbUWBWMxnDmSGZNb4SoDJqpZ65eqU+ZteCC8jPcd7Xb6SA1+Yhh+IF22RQFPqHtE0Yr DhpugNcYyGyR2CHbcW6qI51kGetYHmdZbh39hBjmSF4bF+61DrXFBGtkhowlzQkmV9Us LEiqNTEh4bIKCX2qPhHtoUGBJonvXdkJ3C1GlcPQ5NdmDclbrlkBpITSSufBgg9+d22G r3cQ== X-Gm-Message-State: AOAM53195ti/QxRyFmUPdT3NnzXDv/E7pfsobD22Bdc+4fbYg4OByGFF UwMwTxMWa71MCeTH90RVwBk= X-Google-Smtp-Source: ABdhPJx95+Dp/hSCAWVEjYroTchS3xeyvBFmpqFOQhm0VpXiDBUB5miebEyDTSUNX4bKfEB7KcRzKQ== X-Received: by 2002:a05:600c:2215:: with SMTP id z21mr4166163wml.159.1596544154778; Tue, 04 Aug 2020 05:29:14 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id i4sm30056374wrw.26.2020.08.04.05.29.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 05:29:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Tue, 04 Aug 2020 15:29:12 +0300 From: Yaron Sheffer To: Fabien Imbault , Justin Richer CC: GNAP Mailing List Message-ID: Thread-Topic: [Txauth] Decoupling consent and authorization References: <670C550E-8C82-4E29-9720-E9330C00936F@mit.edu> <085908D8-8D48-4BE5-818A-B5F1232950BA@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3679399753_1736882192" Archived-At: Subject: Re: [Txauth] Decoupling consent and authorization 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, 04 Aug 2020 12:29:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3679399753_1736882192 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable And to those who haven=E2=80=99t been following, there=E2=80=99s already a long list of= use cases on our wiki [1]. Thanks to all who contributed! =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://github.com/ietf-wg-gnap/general/wiki/Use-Cases=20 =20 From: Txauth on behalf of Fabien Imbault Date: Tuesday, August 4, 2020 at 15:23 To: Justin Richer Cc: GNAP Mailing List Subject: Re: [Txauth] Decoupling consent and authorization =20 Thanks Justin. I have written a use case for that. =20 Cheers =20 Fabien =20 On Mon, Aug 3, 2020 at 8:27 PM Justin Richer wrote: Thank you for the clarifications! Yes, I agree that with these simplificati= ons the protocol collapses quite nicely like this. I wonder if this could be= an area where GNAP could provide support for those that need the extra conn= ections but stay out of the way of those that don=E2=80=99t =E2=80=94 like how token int= rospection allows a runtime query of a token=E2=80=99s status and capabilities, bu= t nobody=E2=80=99s suggesting it be mandated for all systems (for what I hope are = obvious reasons!). Then perhaps just like introspection this could be an =E2=80=9C= internal protocol=E2=80=9D that interested AS=E2=80=99s would use, but whether or not it= got used wouldn=E2=80=99t affect the outside of the protocol. This kind of functi= onal layering is a really good design goal. =20 Another thing, this makes me wonder if we should in fact split up the role = of what=E2=80=99s classically been the AS into two functional roles. One part talk= s to the client, the other part interacts with the user (interaction server?= ). The connection between these components is what this =E2=80=9Cinternal protocol= =E2=80=9D would define, though there would be other ways to handle it if you wante= d to, just like with introspection. =20 If you haven=E2=80=99t done so yet, I would recommend that you write up some page= s in the Use Cases wiki describing the kinds of things you=E2=80=99re after: =20 https://github.com/ietf-wg-gnap/general/wiki/Use-Cases =20 =E2=80=94 Justin On Aug 3, 2020, at 12:22 PM, Fabien Imbault wrot= e: =20 Hi Justin,=20 =20 Thanks for your feedback. The point is indeed to evaluate whether this open= s up new capabilities. =20 A preliminary response:=20 =20 1) yes, we would have to sign the request, by any mean supported by GNAP.=20 2) right now it's pretty much hardcoded, which would be fine in some cases;= but more generally the way that requirement is gathered into GNAP still nee= ds to be worked out: probably the Client needs to do a first call to the RS = before. This is important to know if we want to keep it as an implementation= detail, that the Client may not even care about. Could be part of the reque= st (the simplest, but is it fine with privacy requirement if we need to rout= e through the AS?) or we could have continuation Tx specific to the consent = component.=20 3) we have a very basic example (global yes/no) in which we didn't have to = care (the flow either continues or stops), but indeed, we would need a secon= d complete HTTP roundtrip (in a simple implementation) or allow more advance= d communication patterns to reduce roundtrips (we have more flexibility sinc= e the Client in not in the loop here). There's currently a lot of work on 0-= RTT in workgroups such as DIDComm and QUIC that we could leverage for some h= igh perf scenarios. =20 =20 I'll work on a more advanced proposal for these, still a lot of work in ord= er to keep things simple and stupid ;-) =20 Cheers =20 Fabien =20 On Mon, Aug 3, 2020 at 5:33 PM Justin Richer wrote: Fabien, =20 Thanks for writing this up, this is interesting work! So if I=E2=80=99m reading t= his correctly, the =E2=80=9Cinteract_ref=E2=80=9D portion is now also used to connect th= e consent component with the AS, right? I like how it folds in the verificat= ion of components with a really simple calculation, and that allows the step= s to be chained together. I really like that the extra steps don=E2=80=99t affect = what the client needs to know or what it has to do, so a server could deploy= with or without this and not change client behavior.=20 =20 I have a couple questions about how you think this might play out in a depl= oyment: =20 1) Do you think the interact server would sign its request to the AS in 7? = Since it=E2=80=99s a direct HTTP POST this should be able to use any of the signin= g/proof mechanisms that the rest of GNAP would use. 2) How does the interaction server get information about the consent being = gathered, in order to display the appropriate UI to the user? This seems lik= e it could be part of the exchange in 7/8 but I=E2=80=99m not sure what the detail= s would look like, any thoughts there? 3) How does the interaction server communicate the results of the consent b= ack to the AS? It seems like that would require a second round trip. =20 =20 I=E2=80=99m particularly interested in this idea because it could allow standardi= zation of something that OAuth is really bad at: interaction through compone= nts that are not accessed via web browser. Think of it like this: you=E2=80=99ve g= ot an AS that handles the tokens and managing state and all that, but you=E2=80=99= ve got an on-device app to handle the actual consent and user interaction po= rtions. Previously, I=E2=80=99d hand-waved that they=E2=80=99d talk to each other someho= w, but this approach could give us a way for that on-device app to talk back= to the AS, get the information it needs to draw a UI, and continue the requ= est without it needing to have a full view of everything back at the server. =20 =E2=80=94 Justin On Aug 3, 2020, at 7:15 AM, Fabien Imbault wrote= : =20 Hello,=20 =20 This is a new thread.=20 =20 I have just published a proof of concept that separates the interaction fro= m the rest of the AS. The goal is to open up the door to a privacy preservin= g flow such as the one suggested by Denis (the interaction may be handled by= a Client endpoint, if it wishes), as well as to optimize the implementation= to each concern (UX for consent vs authorization flows).=20 =20 Note that it ends up being an implementation detail as far as the Client is= concerned, as the core request/response format wasn't changed from the orig= inal XYZ protocol. =20 The code and documentation is available publicly at: https://github.com/acertio/mvp_gnap_interact =20 The flow is sketched and explained at https://github.com/acertio/mvp_gnap_i= nteract/blob/master/Redirect.md#process =20 Let me know what you think. =20 Cheers =20 Fabien =20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 =20 -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3679399753_1736882192 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

And to those who haven=E2=80=99t been following, there=E2=80= =99s already a long list of use cases on our wiki [1]. Thanks to all who contr= ibuted!

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

<= o:p> 

[1] https://github.com/ietf-wg-gnap/g= eneral/wiki/Use-Cases

 

From= : Txauth <txauth-bo= unces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com&= gt;
Date: Tuesday, August 4, 2020 at 15:23
To: Justin Ri= cher <jricher@mit.edu>
Cc: GNAP Mailing List <txauth@ietf= .org>
Subject: Re: [Txauth] Decoupling consent and authorizatio= n

 

Thanks Justin. I have written a use case for tha= t.

 

Cheers

&nbs= p;

Fabien

<= p class=3DMsoNormal> 

On Mon, = Aug 3, 2020 at 8:27 PM Justin Richer <jr= icher@mit.edu> wrote:

Thank you for the clarificatio= ns! Yes, I agree that with these simplifications the protocol collapses quit= e nicely like this. I wonder if this could be an area where GNAP could provi= de support for those that need the extra connections but stay out of the way= of those that don=E2=80=99t =E2=80=94 like how token introspection allows a runtime que= ry of a token=E2=80=99s status and capabilities, but nobody=E2=80=99s suggesting it be m= andated for all systems (for what I hope are obvious reasons!). Then perhaps= just like introspection this could be an =E2=80=9Cinternal protocol=E2=80=9D that inter= ested AS=E2=80=99s would use, but whether or not it got used wouldn=E2=80=99t affect the= outside of the protocol. This kind of functional layering is a really good = design goal.

 

Another thing, this makes me wonder if we should i= n fact split up the role of what=E2=80=99s classically been the AS into two functi= onal roles. One part talks to the client, the other part interacts with the = user (interaction server?). The connection between these components is what = this =E2=80=9Cinternal protocol=E2=80=9D would define, though there would be other ways = to handle it if you wanted to, just like with introspection.

<= /div>

 

If you haven=E2=80=99t done so yet, I would recommend that you write up some p= ages in the Use Cases wiki describing the kinds of things you=E2=80=99re after:

 

 

=

 =E2=80=94 Justin



On Aug 3, 2020, at 12:22 PM, Fabien Imbault &= lt;fabien.imbault@= gmail.com> wrote:

 <= /o:p>

Hi Justin, 

 

Thanks f= or your feedback. The point is indeed to evaluate whether this opens up new = capabilities.

 <= /p>

A preliminary response: 

 

1) yes, we would have to sign the request, by any mean supported by GN= AP. 

2) right now it's pret= ty much hardcoded, which would be fine in some cases; but more generally the= way that requirement is gathered into GNAP still needs to be worked out: pr= obably the Client needs to do a first call to the RS before. This is importa= nt to know if we want to keep it as an implementation detail, that the Clien= t may not even care about. Could be part of the request (the simplest, but i= s it fine with privacy requirement if we need to route through the AS?) or w= e could have continuation Tx specific to the consent component. 

3) we have a very basic example (globa= l yes/no) in which we didn't have to care (the flow either continues or stop= s), but indeed, we would need a second complete HTTP roundtrip (in a simple = implementation) or allow more advanced communication patterns to reduce roun= dtrips (we have more flexibility since the Client in not in the loop here). = There's currently a lot of work on 0-RTT in workgroups such as DIDComm and Q= UIC that we could leverage for some high perf scenarios.  

 

I'll work on a more advanced proposal for these, still a lot of = work in order to keep things simple and stupid ;-)

=

 

Cheers=

 

Fabien

 

On Mon, Aug 3, 2020 at 5:33 PM= Justin Richer <jricher@= mit.edu> wrote:

Fabien,

 

Thanks for writ= ing this up, this is interesting work! So if I=E2=80=99m reading this correctly, t= he =E2=80=9Cinteract_ref=E2=80=9D portion is now also used to connect the consent compon= ent with the AS, right? I like how it folds in the verification of component= s with a really simple calculation, and that allows the steps to be chained = together. I really like that the extra steps don=E2=80=99t affect what the client = needs to know or what it has to do, so a server could deploy with or without= this and not change client behavior. 

 

I have a coup= le questions about how you think this might play out in a deployment:

 

1) Do you think the interact server would sign its request to t= he AS in 7? Since it=E2=80=99s a direct HTTP POST this should be able to use any o= f the signing/proof mechanisms that the rest of GNAP would use.

2) How does the interaction server get infor= mation about the consent being gathered, in order to display the appropriate= UI to the user? This seems like it could be part of the exchange in 7/8 but= I=E2=80=99m not sure what the details would look like, any thoughts there?

3) How does the interaction server com= municate the results of the consent back to the AS? It seems like that would= require a second round trip.

 

 

=

I=E2=80=99m particularly interested in this idea because i= t could allow standardization of something that OAuth is really bad at: inte= raction through components that are not accessed via web browser. Think of i= t like this: you=E2=80=99ve got an AS that handles the tokens and managing state a= nd all that, but you=E2=80=99ve got an on-device app to handle the actual consent = and user interaction portions. Previously, I=E2=80=99d hand-waved that they=E2=80=99d ta= lk to each other somehow, but this approach could give us a way for that on-= device app to talk back to the AS, get the information it needs to draw a UI= , and continue the request without it needing to have a full view of everyth= ing back at the server.

&nb= sp;

 =E2=80=94 Justin



On Aug 3, 2020, at 7:15 AM= , Fabien Imbault <fabien.imbault@gmail.com> wrote:

 

Hello, 

 

This is a new thread. 

 

I have just published a= proof of concept that separates the interaction from the rest of the AS. Th= e goal is to open up the door to a privacy preserving flow such as the one s= uggested by Denis (the interaction may be handled by a Client endpoint, if i= t wishes), as well as to optimize the implementation to each concern (UX for= consent vs authorization flows). 

 

Note that it ends= up being an implementation detail as far as the Client is concerned, as the= core request/response format wasn't changed from the original XYZ protocol.=

 

The code and documentation is available publicly at:

 

=  

Let me know what you think.

 

Cheers

&nb= sp;

Fabien

<= p class=3DMsoNormal> 

-- Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

 

 = ;

-- Txauth maili= ng list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--B_3679399753_1736882192-- From nobody Tue Aug 4 08:51:55 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 636583A0B5F for ; Tue, 4 Aug 2020 08:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SWCkIrlTGo3B for ; Tue, 4 Aug 2020 08:51:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C223A0B79 for ; Tue, 4 Aug 2020 08:51:51 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 074FpkhO031279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 11:51:47 -0400 From: Justin Richer Message-Id: <2D519099-FF35-4D2C-95BE-A808B67F19B5@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_ECBA7566-7CC3-481D-91B8-630CDC01B26A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 4 Aug 2020 11:51:45 -0400 In-Reply-To: Cc: Denis , "txauth@ietf.org" , Dick Hardt To: Tom Jones References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 15:51:54 -0000 --Apple-Mail=_ECBA7566-7CC3-481D-91B8-630CDC01B26A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s exactly why =E2=80=9Cclient=E2=80=9D and =E2=80=9CRS=E2=80=9D= need to be thought of as a =E2=80=9Crole=E2=80=9D and not an = =E2=80=9Centity=E2=80=9D. An entity can have several roles, and = they=E2=80=99re all about context. The =E2=80=9Cclient=E2=80=9D role is always the =E2=80=9Cclient=E2=80=9D = regardless of whether the entity being the =E2=80=9Cclient=E2=80=9D can = also be an =E2=80=9CRS=E2=80=9D in another context milliseconds later. =E2=80=94 Justin > On Aug 3, 2020, at 5:16 PM, Tom Jones = wrote: >=20 > In our use cases the client and rs are indistinguishable other than = one is a source and the other a sink of data. They can reverse roles = rapidly. I agree that client is not a helpful name. > Peace ..tom >=20 >=20 > On Mon, Aug 3, 2020 at 12:02 PM Justin Richer > wrote: > Hi Denis, >=20 > I think there=E2=80=99s still a problem with the terminology in use = here. What you describe as RS2, which might in fact be an RS unto = itself, is a =E2=80=9CClient=E2=80=9D in OAuth parlance because it is a = client of RS1. What you call a =E2=80=9Cclient=E2=80=9D has no analogue = in the OAuth world, but it is not at all the same as an OAuth client. I = appreciate your mapping of the entities below, but it makes it difficult = to hold a discussion if we aren=E2=80=99t using the same terms. >=20 > The good news is that this isn=E2=80=99t OAuth, and as a new WG we can = define our own terms. The bad news is that this is really hard to do. >=20 > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions, but we=E2=80=99ve got a chance to be more precise with how = we define things. This could mean splitting up things into multiple = roles, or defining new roles for aspects that weren=E2=80=99t in = consideration in the protocol previously. Perhaps what you=E2=80=99re = calling a client below could potentially be considered the = =E2=80=9Cinteraction component=E2=80=9D or =E2=80=9Cconsent gatherer=E2=80= =9D, which was previously a portion of the AS.=20 >=20 > I=E2=80=99ve never been a fan of the term =E2=80=9Cclient=E2=80=9D in = OAuth because it=E2=80=99s too generic and confusing to a lot of = developers, especially the web programmers that OAuth is aimed at. = =E2=80=9CUser Agent=E2=80=9D would be similarly unsuitable for the same = reasons =E2=80=94 both =E2=80=9Cclient=E2=80=9D and =E2=80=9Cuser = agent=E2=80=9D are taken to mean =E2=80=9Cbrowser=E2=80=9D in many = circles. I=E2=80=99d love for us to come up with a new term for this, = but apart from the =E2=80=9CResource Client (RC)=E2=80=9D that I = proposed in the XYZ Draft, I don=E2=80=99t have an answer. >=20 > =E2=80=94 Justin >=20 >> On Aug 3, 2020, at 3:35 AM, Denis > wrote: >>=20 >> Hello Dick, >>=20 >>=20 >> This is a follow-up of the thread: "Reviewing = draft-hardt-xauth-protocol-11". >>=20 >> Hereafter are three exchanges between you and me which triggered this = new thread: >>=20 >> [Dick] The photo sharing example was a driving use case for the = creation of OAuth. >> [Denis] We would need to revisit the original scenario and consider = if it can be addressed in a different way than the original way. >> [Dick] The use case is the same. Is there a different solution you = are proposing ? >>=20 >> My response is : Yes indeed, I have a different solution to address = the same use case. >>=20 >> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >>=20 >> For example, an end-user (resource owner) can grant a printing = service (client) access to her protected photos stored at=20 >> a photo-sharing service (resource server), without sharing her = username and password with the printing service. Instead,=20 >> she authenticates directly with a server trusted by the photo-sharing = service (authorization server), which issues the printing=20 >> service delegation-specific credentials (access token). >>=20 >> There are no further explanations.=20 >>=20 >> Which information will be disclosed by the resource owner to the = authorization server to get "the printing service delegation-specific = credentials"=20 >> is not described. It is a private agreement between the AS and the = RS. It is more than likely that the authorization server will learn = information=20 >> about which operation the resource owner is wishing to perform and = where. Since in OAuth, the access token is supposed to be opaque to the = Client,=20 >> the user will be unable to make sure that her instructions have been = carefully followed. =20 >>=20 >> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they = do not contain a "Privacy Considerations" section.=20 >> Thus, the leakage of information to the AS is not discussed. >>=20 >> It is possible to revisit the original scenario by applying "Privacy = by design" principles.=20 >>=20 >> The scenario can be solved by using an old data transfer method that = has been first described 32 years ago under the name=20 >> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years = later in ISO/IEC 10740-2:1993. >>=20 >> RDT allows two servers to directly exchange large amounts of data = under the supervision of a client by communicating, through the client,=20= >> a reference generated by one server to the other server. RDT does not = use any Authorization Server (AS). This means that no AS is able=20 >> to act as Big Brother and this solves a major privacy concern. >>=20 >> The three entities involved >>=20 >> The Client supporting a User (was the Resource Owner). >> The Photo-sharing service (was the Resource Server) : RS1.=20 >> The Printing service (was the client): RS2. >>=20 >>=20 >> Flow of operations with the Photo-sharing service (RS1) >>=20 >> The Client first connects to the photo-sharing service (RS1) and the = User authenticates to the photo-sharing service (RS1). >>=20 >> RS1 to User: "Please select the operation to be performed". >> Operation selected: "Print pictures using a third party printing = service". >>=20 >> RS1 to User: "Please select a set of pictures to be printed". >> The User selects the pictures. >>=20 >> RS 1 User consent: "Do you agree RS1 to communicate your selection of = pictures to a third party printing service" ? >> If the User consents, RS1 to Client: "Here is the reference to be = used by your printing service to get the selected pictures". >>=20 >> Flow of operations with the Printing service (RS2) >>=20 >> The Client connects to the printing service (RS2) and the User = authenticates to the printing service (RS2). >>=20 >> Note: This allows to make sure that the user has an = account on RS2 so that further operations can be charged to this account=20= >> and that the prints can be sent to a known = address. >>=20 >> RS2 to User: "Please select the operation to be performed". >> Operation : "Print pictures to be received from a photo-sharing = service ". >> RS2 to User: "Please indicate your photo-sharing service".. >> The User responds: RS1. >>=20 >> "Please enter the reference to be used by RS2 to receive the set of = pictures from RS1". >> The Client (or the User) enters the reference generated by RS1. >>=20 >> RS2 contacts RS1 using that reference in order to get the = characteristics and the thumbnails of the pictures to be printed (i.e. = not yet the whole pictures).=20 >>=20 >> RS2 to client: What are your printing preferences for each picture = (e.g. number of prints, size, quality of the paper, resolution, margins, = colours, etc... ) ? >> The User responds to all these questions. >>=20 >> RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do = you agree ? >> If the payment needs to be done on-line, then a payment phase is = inserted. >>=20 >> Continuation of the flow of operations >>=20 >> Final message from RS1 to the Client: "Your selection of pictures = will be soon transmitted to RS2". >> Final message from RS2 to the Client: "Your prints will be soon on = their way". >>=20 >> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding = to this reference. >>=20 >> Some of the advantages of RDT >>=20 >> An end-user can grant a printing service (RS2) access to her = protected photos stored at a photo-sharing service (RS1), >> without sharing her username and password with the printing service. >> Neither RS1, nor RS2 need to use or to trust any AS. This solves the = Big Brother privacy issue. >> Any authentication method supported by RS1 or RS2 can be used by the = User. >> The User can use any photo-sharing service (RS1) with any printing = service (RS2), as long as they both support RDT. >> The User consent is first performed with the photo-sharing service = (RS1) and then after with the printing service (RS2). >> The reference generated by RS1 will only be accepted by RS1 during a = time period. >> The reference generated by RS1 allows RS2 to query first the = thumbnails and then after the pictures selected by the User at RS1. >> The data transfer of the pictures selected at RS1 by the User is = performed asynchronously from RS1 to RS2 as a back-office operation. >> Questions: What would be the full scenario of this use case using = OAuth ? What about Privacy Considerations ? >>=20 >> Denis >>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_ECBA7566-7CC3-481D-91B8-630CDC01B26A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s exactly why =E2=80=9Cclient=E2=80=9D and = =E2=80=9CRS=E2=80=9D need to be thought of as a =E2=80=9Crole=E2=80=9D = and not an =E2=80=9Centity=E2=80=9D. An entity can have several roles, = and they=E2=80=99re all about context.

The =E2=80=9Cclient=E2=80=9D role is = always the =E2=80=9Cclient=E2=80=9D regardless of whether the entity = being the =E2=80=9Cclient=E2=80=9D can also be an =E2=80=9CRS=E2=80=9D = in another context milliseconds later.

 =E2=80=94 Justin

On Aug 3, 2020, at 5:16 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

In our use cases the client and = rs are indistinguishable other than one is a source and the other a sink = of data. They can reverse roles rapidly. I agree that client is not a = helpful name.
Peace = ..tom


On Mon, Aug = 3, 2020 at 12:02 PM Justin Richer <jricher@mit.edu> wrote:
Hi Denis,

I think there=E2=80=99s still a problem with the terminology = in use here. What you describe as RS2, which might in fact be an RS unto = itself, is a =E2=80=9CClient=E2=80=9D in OAuth parlance because it is a client of RS1. What you call a =E2=80=9Cclient=E2=80= =9D has no analogue in the OAuth world, but it is not at all the same as = an OAuth client. I appreciate your mapping of the entities below, but it = makes it difficult to hold a discussion if we aren=E2=80=99t using the = same terms.

The = good news is that this isn=E2=80=99t OAuth, and as a new WG we can = define our own terms. The bad news is that this is really hard to = do.

In GNAP, = we shouldn=E2=80=99t just re-use existing terms with new definitions, = but we=E2=80=99ve got a chance to be more precise with how we define = things. This could mean splitting up things into multiple roles, or = defining new roles for aspects that weren=E2=80=99t in consideration in = the protocol previously. Perhaps what you=E2=80=99re calling a client = below could potentially be considered the =E2=80=9Cinteraction = component=E2=80=9D or =E2=80=9Cconsent gatherer=E2=80=9D, which was = previously a portion of the AS. 

I=E2=80=99ve never been a fan of the = term =E2=80=9Cclient=E2=80=9D in OAuth because it=E2=80=99s too generic = and confusing to a lot of developers, especially the web programmers = that OAuth is aimed at. =E2=80=9CUser Agent=E2=80=9D would be similarly = unsuitable for the same reasons =E2=80=94 both =E2=80=9Cclient=E2=80=9D = and =E2=80=9Cuser agent=E2=80=9D are taken to mean =E2=80=9Cbrowser=E2=80=9D= in many circles. I=E2=80=99d love for us to come up with a new term for = this, but apart from the =E2=80=9CResource Client (RC)=E2=80=9D that I = proposed in the XYZ Draft, I don=E2=80=99t have an answer.

 =E2=80=94 = Justin

On Aug 3, 2020, at 3:35 AM, = Denis <denis.ietf@free.fr> wrote:

=20

Hello Dick,


This is a = follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]    The photo sharing example was a = driving use case for the creation of OAuth.
[Denis]  We would need to revisit the original scenario = and consider if it can be addressed in a different way than the original way.
[Dick]   The use case is the same. Is there a = different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed. 

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client, =
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : = RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

          &nb= sp; Note: This allows to make sure that the user = has an account on RS2 so that further operations can be charged to this account
=             &n= bsp;         and that the prints = can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service"..
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by = RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82=AC ? = Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be = soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1. =
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office = operation.

Questions: What would be the full scenario of = this use case using OAuth ? What about Privacy Considerations ?

Denis


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

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

= --Apple-Mail=_ECBA7566-7CC3-481D-91B8-630CDC01B26A-- From nobody Tue Aug 4 10:31:33 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 D33813A0DC8 for ; Tue, 4 Aug 2020 10:31:31 -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 7fIenLHH4fFs for ; Tue, 4 Aug 2020 10:31:29 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 E27143A0DC4 for ; Tue, 4 Aug 2020 10:31:28 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id t6so31576102ljk.9 for ; Tue, 04 Aug 2020 10:31:28 -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=FiPWdwnIrX79E5eiCzHNh2N8aSTZoUTj0fjEFZ5pK64=; b=P3RboxalD2A7MLAejgIBxDX0JpsUumVRXG+eCREQkfcVt/qr11m6NZK3KAy8PAYA6O lzS1lTSc/Lkiz9erWhowsSBf8jQHo4foB1wCXMXbWxwvmEI8QpKtX3d4DNFKYl4iv1PU +d2Qau9RJXPx+ywFUxcpQSDGaPupNCbKnrAnuCtejZcPa5TyNDvAME2VoH1aS2NIO2eH zF3oG5hHpEZnmR4oAPwaTnYBvge00pF+UUwXsBqigS6LwGiLnLnf5hbjpeONY1xz6PBh lRZ00iquDZzglQReUfQWgriYIdqo44KOn/B7bsRw/zU7KilCuq3EyElc2cbFRUB1R7Pc 6ihA== 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=FiPWdwnIrX79E5eiCzHNh2N8aSTZoUTj0fjEFZ5pK64=; b=UOowcQtMfKVcmXrb0MZDpajna8uCUhFCueUjjFQw5E43wP1se3XjbzvinBAshKCm36 15h80PUoMWWpDm0RfnlFoQb1tkKR/2HKAOIPOQ9T3ayspBeClK9383SbfFXWbvPL1Nnp KwKuQGLWc3TcPuhdo+8J5C6DC4Tb31glZwOeAiPGEj+OxSGQzHYczcszjZtuYUFzP1za AX9i4DorA8IWO5ix3ZhG97Yzth1unajPNcMMyhtXXYAIcIHFOORwddYrkOonz71xdn9o HDJqBCO1Qw2sLkiyIq6sgFkj5Yb7Grx/w2GjUoUp2gIKm4B8ON0X16x0OW2g9cVtCKf2 +j/w== X-Gm-Message-State: AOAM530h+9PqOynrWJvn179bqtDNlDqulup/h1IfMCxz07IzgvZFdrsl /dAJZg8UP4BykeRH/rF2vDqdk0SLU4wP84iCzKU= X-Google-Smtp-Source: ABdhPJz1RiuY2euOS5Tpa3MyXA9NxllMEWzNAf37OuMEObRR49Yl72MPLK9sUC3hHnUcYkJr/CqjMRS9gMFllyShslk= X-Received: by 2002:a2e:999a:: with SMTP id w26mr11058223lji.242.1596562286894; Tue, 04 Aug 2020 10:31:26 -0700 (PDT) MIME-Version: 1.0 References: <2D519099-FF35-4D2C-95BE-A808B67F19B5@mit.edu> In-Reply-To: <2D519099-FF35-4D2C-95BE-A808B67F19B5@mit.edu> From: Dick Hardt Date: Tue, 4 Aug 2020 10:30:50 -0700 Message-ID: To: Justin Richer Cc: Tom Jones , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f8e35d05ac109f05" Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 17:31:32 -0000 --000000000000f8e35d05ac109f05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to Client and RS being the roles they are playing in the protocol. =E1=90=A7 On Tue, Aug 4, 2020 at 8:51 AM Justin Richer wrote: > That=E2=80=99s exactly why =E2=80=9Cclient=E2=80=9D and =E2=80=9CRS=E2=80= =9D need to be thought of as a =E2=80=9Crole=E2=80=9D and > not an =E2=80=9Centity=E2=80=9D. An entity can have several roles, and th= ey=E2=80=99re all about > context. > > The =E2=80=9Cclient=E2=80=9D role is always the =E2=80=9Cclient=E2=80=9D = regardless of whether the entity > being the =E2=80=9Cclient=E2=80=9D can also be an =E2=80=9CRS=E2=80=9D in= another context milliseconds > later. > > =E2=80=94 Justin > > On Aug 3, 2020, at 5:16 PM, Tom Jones > wrote: > > In our use cases the client and rs are indistinguishable other than one i= s > a source and the other a sink of data. They can reverse roles rapidly. I > agree that client is not a helpful name. > Peace ..tom > > > On Mon, Aug 3, 2020 at 12:02 PM Justin Richer wrote: > >> Hi Denis, >> >> I think there=E2=80=99s still a problem with the terminology in use here= . What >> you describe as RS2, which might in fact be an RS unto itself, is a >> =E2=80=9CClient=E2=80=9D in OAuth parlance because it is *a client of RS= 1*. What you >> call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, but = it is not at all >> the same as an OAuth client. I appreciate your mapping of the entities >> below, but it makes it difficult to hold a discussion if we aren=E2=80= =99t using >> the same terms. >> >> The good news is that this isn=E2=80=99t OAuth, and as a new WG we can d= efine our >> own terms. The bad news is that this is really hard to do. >> >> In GNAP, we shouldn=E2=80=99t just re-use existing terms with new defini= tions, >> but we=E2=80=99ve got a chance to be more precise with how we define thi= ngs. This >> could mean splitting up things into multiple roles, or defining new role= s >> for aspects that weren=E2=80=99t in consideration in the protocol previo= usly. >> Perhaps what you=E2=80=99re calling a client below could potentially be = considered >> the =E2=80=9Cinteraction component=E2=80=9D or =E2=80=9Cconsent gatherer= =E2=80=9D, which was previously a >> portion of the AS. >> >> I=E2=80=99ve never been a fan of the term =E2=80=9Cclient=E2=80=9D in OA= uth because it=E2=80=99s too >> generic and confusing to a lot of developers, especially the web >> programmers that OAuth is aimed at. =E2=80=9CUser Agent=E2=80=9D would b= e similarly >> unsuitable for the same reasons =E2=80=94 both =E2=80=9Cclient=E2=80=9D = and =E2=80=9Cuser agent=E2=80=9D are taken >> to mean =E2=80=9Cbrowser=E2=80=9D in many circles. I=E2=80=99d love for = us to come up with a new >> term for this, but apart from the =E2=80=9CResource Client (RC)=E2=80=9D= that I proposed in >> the XYZ Draft, I don=E2=80=99t have an answer. >> >> =E2=80=94 Justin >> >> On Aug 3, 2020, at 3:35 AM, Denis wrote: >> >> Hello Dick, >> >> This is a follow-up of the thread: "Reviewing >> draft-hardt-xauth-protocol-11". >> >> Hereafter are three exchanges between you and me which triggered this ne= w >> thread: >> >> [Dick] The photo sharing example was a driving use case for the >> creation of OAuth. >> [Denis] We would need to revisit the original scenario and consider if >> it can be addressed in a different way than the original way. >> [Dick] The use case is the same. Is there a different solution you are >> proposing ? >> >> My response is : Yes indeed, I have a different solution to address the >> same use case. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >> >> For example, an end-user (resource owner) can grant a printing service >> (client) access to her protected photos stored at >> a photo-sharing service (resource server), without sharing her username >> and password with the printing service. Instead, >> she authenticates directly with a server trusted by the photo-sharing >> service (authorization server), which issues the printing >> service delegation-specific credentials (access token). >> >> There are no further explanations. >> >> Which information will be disclosed by the resource owner to the >> authorization server to get "the printing service delegation-specific >> credentials" >> is not described. It is a private agreement between the AS and the RS. I= t >> is more than likely that the authorization server will learn information >> about which operation the resource owner is wishing to perform and where= . >> Since in OAuth, the access token is supposed to be opaque to the Client, >> the user will be unable to make sure that her instructions have been >> carefully followed. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do >> not contain a "Privacy Considerations" section. >> Thus, the leakage of information to the AS is not discussed. >> >> It is possible to revisit the original scenario by applying "Privacy by >> design" principles. >> >> The scenario can be solved by using an old data transfer method that has >> been first described 32 years ago under the name >> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years late= r >> in ISO/IEC 10740-2:1993. >> >> RDT allows two servers to directly exchange large amounts of data under >> the supervision of a client by communicating, through the client, >> a reference generated by one server to the other server. RDT does not us= e >> any Authorization Server (AS). This means that no AS is able >> to act as Big Brother and this solves a major privacy concern. >> >> >> * The three entities involved * >> The Client supporting a User (was the Resource Owner). >> The Photo-sharing service (was the Resource Server) : RS1. >> The Printing service (was the client): RS2. >> >> >> >> *Flow of operations with the Photo-sharing service (RS1) *The Client >> first connects to the photo-sharing service (RS1) and the User >> authenticates to the photo-sharing service (RS1). >> >> RS1 to User: "Please select the operation to be performed". >> Operation selected: "Print pictures using a third party printing service= ". >> >> RS1 to User: "Please select a set of pictures to be printed". >> The User selects the pictures. >> >> RS 1 User consent: "Do you agree RS1 to communicate your selection of >> pictures to a third party printing service" ? >> If the User consents, RS1 to Client: "Here is the reference to be used b= y >> your printing service to get the selected pictures". >> >> * Flow of operations with the Printing service* ( >> *RS2) * >> The Client connects to the printing service (RS2) and the User >> authenticates to the printing service (RS2). >> >> *Note*: This allows to make sure that the user has an >> account on RS2 so that further operations can be charged to this account >> and that the prints can be sent to a known address= . >> >> RS2 to User: "Please select the operation to be performed". >> Operation : "Print pictures to be received from a photo-sharing service = ". >> RS2 to User: "Please indicate your photo-sharing service".. >> The User responds: RS1. >> >> "Please enter the reference to be used by RS2 to receive the set of >> pictures from RS1". >> The Client (or the User) enters the reference generated by RS1. >> >> RS2 contacts RS1 using that reference in order to get the characteristic= s >> and the thumbnails of the pictures to be printed (i.e. not yet the whole >> pictures). >> >> RS2 to client: What are your printing preferences for each picture (e.g. >> number of prints, size, quality of the paper, resolution, margins, colou= rs, >> etc... ) ? >> The User responds to all these questions. >> >> RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do you = agree ? >> If the payment needs to be done on-line, then a payment phase is inserte= d. >> >> >> >> * Continuation of the flow of operations *Final message from RS1 to the >> Client: "Your selection of pictures will be soon transmitted to RS2". >> Final message from RS2 to the Client: "Your prints will be soon on their >> way". >> >> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to >> this reference. >> >> * Some of the advantages of RDT* >> >> 1. An end-user can grant a printing service (RS2) access to her >> protected photos stored at a photo-sharing service (RS1), >> without sharing her username and password with the printing service. >> 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves >> the Big Brother privacy issue. >> 3. Any authentication method supported by RS1 or RS2 can be used by >> the User. >> 4. The User can use any photo-sharing service (RS1) with any printing >> service (RS2), as long as they both support RDT. >> 5. The User consent is first performed with the photo-sharing service >> (RS1) and then after with the printing service (RS2). >> 6. The reference generated by RS1 will only be accepted by RS1 during >> a time period. >> 7. The reference generated by RS1 allows RS2 to query first the >> thumbnails and then after the pictures selected by the User at RS1. >> 8. The data transfer of the pictures selected at RS1 by the User is >> performed asynchronously from RS1 to RS2 as a back-office operation. >> >> *Questions*: What would be the full scenario of this use case using >> OAuth ? What about Privacy Considerations ? >> >> Denis >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000f8e35d05ac109f05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to Client and RS being the roles they are playing in th= e protocol.=C2=A0
3D""=E1=90=A7

On Tue, Aug 4, 2020 at = 8:51 AM Justin Richer <jricher@mit.ed= u> wrote:
That=E2=80=99s exactly why =E2= =80=9Cclient=E2=80=9D and =E2=80=9CRS=E2=80=9D need to be thought of as a = =E2=80=9Crole=E2=80=9D and not an =E2=80=9Centity=E2=80=9D. An entity can h= ave several roles, and they=E2=80=99re all about context.

The =E2=80=9Cclient=E2=80=9D role is always the =E2=80=9Cclient=E2=80=9D = regardless of whether the entity being the =E2=80=9Cclient=E2=80=9D can als= o be an =E2=80=9CRS=E2=80=9D in another context milliseconds later.

=C2=A0=E2=80=94 Justin

On Aug 3, 2020, at 5:16 PM, Tom Jones <thomasclinganjones@gmail.com&= gt; wrote:

In our use cases the client and r= s are indistinguishable other than one is a source and the other a sink of = data. They can reverse roles rapidly. I agree that client is not a helpful = name.
Peace ..= tom


On Mon, Aug 3, 2020 at 12:02 PM Justin Riche= r <jricher@mit.edu<= /a>> wrote:
<= div>Hi Denis,

I think there=E2=80=99s still a problem wi= th the terminology in use here. What you describe as RS2, which might in fa= ct be an RS unto itself, is a =E2=80=9CClient=E2=80=9D in OAuth parlance be= cause it is a client of RS1. What you call a=C2=A0=E2=80=9Cclient=E2= =80=9D has no analogue in the OAuth world, but it is not at all the same as= an OAuth client. I appreciate your mapping of the entities below, but it m= akes it difficult to hold a discussion if we aren=E2=80=99t using the same = terms.

The good news is that this isn=E2=80=99t OA= uth, and as a new WG we can define our own terms. The bad news is that this= is really hard to do.

In GNAP, we shouldn=E2=80= =99t just re-use existing terms with new definitions, but we=E2=80=99ve got= a chance to be more precise with how we define things. This could mean spl= itting up things into multiple roles, or defining new roles for aspects tha= t weren=E2=80=99t in consideration in the protocol previously. Perhaps what= you=E2=80=99re calling a client below could potentially be considered the = =E2=80=9Cinteraction component=E2=80=9D or =E2=80=9Cconsent gatherer=E2=80= =9D, which was previously a portion of the AS.=C2=A0

I=E2=80=99ve never been a fan of the term =E2=80=9Cclient=E2=80=9D in OA= uth because it=E2=80=99s too generic and confusing to a lot of developers, = especially the web programmers that OAuth is aimed at. =E2=80=9CUser Agent= =E2=80=9D would be similarly unsuitable for the same reasons =E2=80=94 both= =E2=80=9Cclient=E2=80=9D and =E2=80=9Cuser agent=E2=80=9D are taken to mea= n =E2=80=9Cbrowser=E2=80=9D in many circles. I=E2=80=99d love for us to com= e up with a new term for this, but apart from the =E2=80=9CResource Client = (RC)=E2=80=9D that I proposed in the XYZ Draft, I don=E2=80=99t have an ans= wer.

=C2=A0=E2=80=94 Justin

On Aug 3, 2020, at 3:35 AM, Denis <denis.ietf@free.fr> wrote:
=20

Hello Dick,


This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]=C2=A0=C2=A0=C2=A0 The photo sharing example was a driving = use case for the creation of OAuth.
[Denis]=C2=A0 We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]=C2=A0=C2=A0 The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printin= g service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed.=C2=A0

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a= few years later in IS= O/IEC 10740-2:1993.=

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed&qu= ot;.
Operation selected: "Print pictures using a third party printi= ng service".

RS1 to User: "Please select a set of pictures to be printed&qu= ot;.
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and that the p= rints can be sent to a known address.

RS2 to User: "Please select the operation to be performed"= ;.
Operation : "Print pictures to be received from a photo-sharin= g service ".
RS2 to User: "Please indicate your photo-sharing service"= ..
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the s= et of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do= you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor= RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authenticati= on method supported by RS1 or RS2 can be used by the User.
  4. The User can use= any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent= is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference ge= nerated by RS1 will only be accepted by RS1 during a time period.
  7. The reference ge= nerated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfe= r of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.=

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis


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

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

--000000000000f8e35d05ac109f05-- From nobody Tue Aug 4 10:35:22 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 9240B3A0D7B for ; Tue, 4 Aug 2020 10:35:20 -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 k0Iu10iJEc3U for ; Tue, 4 Aug 2020 10:35:17 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 293163A0D7A for ; Tue, 4 Aug 2020 10:35:17 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id k13so22850747lfo.0 for ; Tue, 04 Aug 2020 10:35:17 -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=7l+WASMVls6prFlTNUp8t24/1Ap2TzRhzCyqs31Qd0U=; b=t/eWgvP8E4F8ldr49dheZ1wOAlb6PLPlI0zhWNfyI+GUfRDmYRPdgrE57uWBq0yq1E ecUwo4jyLC6DEPuy2omV+SW/IkDkFtzHimMuZ3BWPUSH7+kq8gSWG5trKMztKSHBZFGX JMZLkHXvVmXBh9x3H9WofaiIAwjWIzXrUSCzpLTssNqUcDvC2UhY3ZbHqwCNc7vbqw08 1W023janPfY6Wnymf8O6LVy8XosmCANeTbqIrN7bpjxa5MFLeC8Seh71OC+HG1YchoL9 hvLdJ7hlewMCfvFVSPj5r73udFgYOaiuGeFCNNvYg6CJgNaDlmJC0EHbtZVt9Ja0LlqE Dv3w== 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=7l+WASMVls6prFlTNUp8t24/1Ap2TzRhzCyqs31Qd0U=; b=em/ZHjmPSbpAnXnVBnmUFXhQVpypYBQDZSEekoPSVbDjhYhlSFqEjLtynH5cw/1jVX cEQH+SVTMQVZ6eSQwyA6bbLNhcXWfs8k1mveEdBY6r39iNrIygwF/kPyKXwpqc08qUzx 0dn0osdhKOor4XsA4QUxAj1UsR2220j+EfXh7u4HuD/V/odncWnWA9Dh+Vs/1Qrdi2m0 wUrcIlpzoPe7mP1aOZcWuHVBiVfVNBfuG5uAhAMvZ69DTYTTbNoJYQfNOvTere/cMiGb /RESNg7aQq/bH9Iudb4Ln195XqpIsz5v2sAjzLt3V89wNlKDbBoFFuIKSHWQONmBJAih 9yvA== X-Gm-Message-State: AOAM5335uzenLSv5CZFsFtVhhUpDSkY8hHhB+4xgwMjV+SLnA94+J5Kv iLbhJb906vIaepn513i8EP254YzYJID1sv9ND74= X-Google-Smtp-Source: ABdhPJyJS3M8i9dXb/+rH9rCjh5DHWAbE8HPWk7Y/YtaK5famnAtkTFGchZwdKprB8ZaRO7khGg7zjKGs4lr5Lq5C/I= X-Received: by 2002:a19:8044:: with SMTP id b65mr11406032lfd.91.1596562514976; Tue, 04 Aug 2020 10:35:14 -0700 (PDT) MIME-Version: 1.0 References: <722214c8-59f6-ec8e-f4d1-f77682cceb52@free.fr> In-Reply-To: <722214c8-59f6-ec8e-f4d1-f77682cceb52@free.fr> From: Dick Hardt Date: Tue, 4 Aug 2020 10:34:38 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000091266905ac10ad0f" Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 17:35:21 -0000 --00000000000091266905ac10ad0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Denis I don't think it is productive to redefine terms that are well understood. "The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)" Does not answer the question of how the User authenticates to the RS. This implies the user has an account at RS2. If that is the case, it is not just acting in the role of a resource server. /Dick =E1=90=A7 On Tue, Aug 4, 2020 at 2:28 AM Denis wrote: > Hi Dick, > > Hi Denis > > In your proposed flow, how does RS2 know who the user is that it is > dealing with? > > The response is in the text: "The Client connects to the printing service > (RS2) and the User authenticates to the printing service (RS2)". > > In OAuth, the AS authenticates the User for the RS. In the photo sharing > example, the AS and RS are from the same organization, so the AS > knowing what the RS was doing was not an issue. > > Nevertheless, a full description is still missing and might help to bette= r > understand the privacy issues. > > What you call a Client is not an OAuth Client, but is more of an agent fo= r > the User. > > RFC 6749 states: > > In OAuth, the client requests access to resources controlled by the > resource owner and hosted by the resource server, > and is issued a different set of credentials than those of the resource > owner. > > This is how I use the term client which fits with the Client-Server model= . > > However, RFC 6749 also states in section 1.1 (Roles) : > > client > An application making protected resource requests on behalf of the > resource owner and with its authorization. > > This is clearly not how I use the term client. > > The term "User Agent" might grasp the concept, but I clearly like better > the term "Client", > as long as we define the use of this term in the context of GNAP. > Denis > > Microsoft InfoCards comes to mind as a comparable architecture, and it > seems aligned with what Tom is asking for. > > > > > > On Mon, Aug 3, 2020 at 12:35 AM Denis wrote: > >> Hello Dick, >> >> This is a follow-up of the thread: "Reviewing >> draft-hardt-xauth-protocol-11". >> >> Hereafter are three exchanges between you and me which triggered this ne= w >> thread: >> >> [Dick] The photo sharing example was a driving use case for the >> creation of OAuth. >> [Denis] We would need to revisit the original scenario and consider if >> it can be addressed in a different way than the original way. >> [Dick] The use case is the same. Is there a different solution you are >> proposing ? >> >> My response is : Yes indeed, I have a different solution to address the >> same use case. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >> >> For example, an end-user (resource owner) can grant a printing service >> (client) access to her protected photos stored at >> a photo-sharing service (resource server), without sharing her username >> and password with the printing service. Instead, >> she authenticates directly with a server trusted by the photo-sharing >> service (authorization server), which issues the printing >> service delegation-specific credentials (access token). >> >> There are no further explanations. >> >> Which information will be disclosed by the resource owner to the >> authorization server to get "the printing service delegation-specific >> credentials" >> is not described. It is a private agreement between the AS and the RS. I= t >> is more than likely that the authorization server will learn information >> about which operation the resource owner is wishing to perform and where= . >> Since in OAuth, the access token is supposed to be opaque to the Client, >> the user will be unable to make sure that her instructions have been >> carefully followed. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do >> not contain a "Privacy Considerations" section. >> Thus, the leakage of information to the AS is not discussed. >> >> It is possible to revisit the original scenario by applying "Privacy by >> design" principles. >> >> The scenario can be solved by using an old data transfer method that has >> been first described 32 years ago under the name >> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years late= r >> in ISO/IEC 10740-2:1993. >> >> RDT allows two servers to directly exchange large amounts of data under >> the supervision of a client by communicating, through the client, >> a reference generated by one server to the other server. RDT does not us= e >> any Authorization Server (AS). This means that no AS is able >> to act as Big Brother and this solves a major privacy concern. >> >> >> * The three entities involved * >> The Client supporting a User (was the Resource Owner). >> The Photo-sharing service (was the Resource Server) : RS1. >> The Printing service (was the client): RS2. >> >> >> >> *Flow of operations with the Photo-sharing service (RS1) *The Client >> first connects to the photo-sharing service (RS1) and the User >> authenticates to the photo-sharing service (RS1). >> >> RS1 to User: "Please select the operation to be performed". >> Operation selected: "Print pictures using a third party printing service= ". >> >> RS1 to User: "Please select a set of pictures to be printed". >> The User selects the pictures. >> >> RS 1 User consent: "Do you agree RS1 to communicate your selection of >> pictures to a third party printing service" ? >> If the User consents, RS1 to Client: "Here is the reference to be used b= y >> your printing service to get the selected pictures". >> >> * Flow of operations with the Printing service* ( >> *RS2) * >> The Client connects to the printing service (RS2) and the User >> authenticates to the printing service (RS2). >> >> *Note*: This allows to make sure that the user has an >> account on RS2 so that further operations can be charged to this account >> and that the prints can be sent to a known address= . >> >> RS2 to User: "Please select the operation to be performed". >> Operation : "Print pictures to be received from a photo-sharing service = ". >> RS2 to User: "Please indicate your photo-sharing service". >> The User responds: RS1. >> >> "Please enter the reference to be used by RS2 to receive the set of >> pictures from RS1". >> The Client (or the User) enters the reference generated by RS1. >> >> RS2 contacts RS1 using that reference in order to get the characteristic= s >> and the thumbnails of the pictures to be printed (i.e. not yet the whole >> pictures). >> >> RS2 to client: What are your printing preferences for each picture (e.g. >> number of prints, size, quality of the paper, resolution, margins, colou= rs, >> etc... ) ? >> The User responds to all these questions. >> >> RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do you = agree ? >> If the payment needs to be done on-line, then a payment phase is inserte= d. >> >> >> >> * Continuation of the flow of operations *Final message from RS1 to the >> Client: "Your selection of pictures will be soon transmitted to RS2". >> Final message from RS2 to the Client: "Your prints will be soon on their >> way". >> >> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to >> this reference. >> >> * Some of the advantages of RDT* >> >> 1. An end-user can grant a printing service (RS2) access to her >> protected photos stored at a photo-sharing service (RS1), >> without sharing her username and password with the printing service. >> 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves >> the Big Brother privacy issue. >> 3. Any authentication method supported by RS1 or RS2 can be used by >> the User. >> 4. The User can use any photo-sharing service (RS1) with any printing >> service (RS2), as long as they both support RDT. >> 5. The User consent is first performed with the photo-sharing service >> (RS1) and then after with the printing service (RS2). >> 6. The reference generated by RS1 will only be accepted by RS1 during >> a time period. >> 7. The reference generated by RS1 allows RS2 to query first the >> thumbnails and then after the pictures selected by the User at RS1. >> 8. The data transfer of the pictures selected at RS1 by the User is >> performed asynchronously from RS1 to RS2 as a back-office operation. >> >> *Questions*: What would be the full scenario of this use case using >> OAuth ? What about Privacy Considerations ? >> >> Denis >> > > --00000000000091266905ac10ad0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Denis

I don't think it is productiv= e to redefine terms that are well understood.

"The Client connects to the printing ser= vice (RS2) and the User authenticates to the printing service (RS2)"

Does not answer the question of how the = User authenticates to the RS. This implies the user has an account=C2=A0at = RS2. If that is the case, it is not just acting in the role of a resource s= erver.

/Dick

3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Tue, Aug= 4, 2020 at 2:28 AM Denis <denis.i= etf@free.fr> wrote:
=20 =20 =20
Hi Dick,

=20
Hi Denis

In your proposed flow, how does RS2 know who the user is that it is dealing with?

The response is in the text: "The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)".

In OAuth, the AS authenticates the User for the=C2=A0RS. In th= e photo sharing example, the AS and RS are from the same organization, so the AS knowing=C2=A0what the RS was doing was no= t an issue.

Nevertheless, a full description is still missing and might help to better understand the privacy issues.

What you call a Client is not an OAuth Client, but is more of an agent for the User.

RFC 6749 states:

In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server,
and is issued a different set of credentials than those of the resource owner.

This is how I use the term client which fits with the Client-Server model.

However, RFC 6749 also states in section 1.1 (Roles) :

client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An application making protected reso= urce requests on behalf of the resource owner and with its authorization.

This is clearly not how I use the term client.

The term "User Agent" might grasp the concept, but I clear= ly like better the term "Client",
as long as we define the use of this term in the context of GNAP.

Denis

Microsoft InfoCards comes to mind as a comparable architecture, and it seems aligned with what Tom is asking for.





On Mon, Aug 3, 2020 at 12:35 AM Denis <denis.ietf@free.fr> wrote:

Hello Dick,

This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".=

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]=C2=A0=C2=A0=C2=A0 The photo sharing example was a driving use case for the creation of OAuth.
[Denis]=C2=A0 We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]=C2=A0=C2=A0 The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed.=C2=A0

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (198= 8) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed". Operation selected: "Print pictures using a third part= y printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate yo= ur selection of pictures to a th= ird party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)=

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and t= hat the prints can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to recei= ve the set of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82= =AC ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints wil= l be = soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.
 Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis


--00000000000091266905ac10ad0f-- From nobody Tue Aug 4 11:53:24 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 19DA83A1081 for ; Tue, 4 Aug 2020 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xveQPajp5Fuc for ; Tue, 4 Aug 2020 11:53:21 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005BA3A109F for ; Tue, 4 Aug 2020 11:53:20 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 074IrDT3004981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 Aug 2020 14:53:15 -0400 Date: Tue, 4 Aug 2020 11:53:13 -0700 From: Benjamin Kaduk To: Denis Cc: "txauth@ietf.org" Message-ID: <20200804185313.GT92412@kduck.mit.edu> References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 18:53:23 -0000 Hi Denis, On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > Hi Justin, > > Since you replied in parallel, I will make a response similar to the one > I sent to Dick. > > > Hi Denis, > > > > I think there’s still a problem with the terminology in use here. What > > you describe as RS2, which might in fact be an RS unto itself, is a > > “Client” in OAuth parlance because it is /a client of RS1/. What you > > call a “client” has no analogue in the OAuth world, but it is not at > > all the same as an OAuth client. I appreciate your mapping of the > > entities below, but it makes it difficult to hold a discussion if we > > aren’t using the same terms. > > > > The good news is that this isn’t OAuth, and as a new WG we can define > > our own terms. The bad news is that this is really hard to do. > > > > In GNAP, we shouldn’t just re-use existing terms with new definitions, > > but we’ve got a chance to be more precise with how we define things. > > In the ISO context, each document must define its own terminology. The > boiler plate for RFCs does not mandate a terminology or definitions section > but does not prevent it either. The vocabulary is limited and as long as > we clearly define what our terms are meaning, we can re-use a term already > used in another RFC. This is also the ISO approach. Just because we can do something does not necessarily mean that it is a good idea to do so. We are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms from OAuth 2.0 but with different definitions may lead to unnecessary confusion. If I understand correctly, a similar reasoning prompted Dick to use the term "GS" in XAuth, picking a name that was not already used in OAuth 2.0. -Ben From nobody Tue Aug 4 12:32:49 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 0DB533A1145 for ; Tue, 4 Aug 2020 12:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch 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 hCu9dpDMUF-2 for ; Tue, 4 Aug 2020 12:32:46 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 38B933A1141 for ; Tue, 4 Aug 2020 12:32:46 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id a65so22293656otc.8 for ; Tue, 04 Aug 2020 12:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dm11nECxBMXC6pD40LBIJ+x3ZrOAyGALvHti0/a/xn4=; b=Pg3hPRoTfLb5XNa9gcOpq4vbexC7cli/jNlHlHxcnGzxULvIcx2f2FOf4hCWpRzPO5 G4E9biMnNpmnUlXGRJ3/P7TTZvuLA/z3K92eJZZDSstL7l9hobJqIA8cbXkIpUtph/8X ad1BlzhS2eS72UeDeqftmgimS8NIUzLfG0q84= 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=dm11nECxBMXC6pD40LBIJ+x3ZrOAyGALvHti0/a/xn4=; b=uMfYHEOTglC2BYDPW28GhapuPTaBwEkDGbu6n951FG431sS+VxhlkLBgQV6zqiEemw l9vlMa+/p997WqzaIfD0B4SaTCVwxCp6/B9r6hXmYbmRmsKjCToC/wPYxbXANnUhYrEy E1wtAYuhKmXcWHc957fBCoCTGseHXgtRRgT3BFxhYBP3BGLBbwRKgRUCWNfBcWdteqhc ZRZQwYUxD0nrqFMQF2muKjnmvJ4KQdRFc8oVce4bme3JjTZTeYySYCL7JJpTkv2LaZnQ qoo7XngptjBlKhGk+myWjp4oWjwi03TLrnbeAwhf7Wqk+2M9puysEGC4kHU9xdUdaO/h qEmw== X-Gm-Message-State: AOAM533MptEB7aq+GMnUmlUR7cGcK/khDC2hJCRrjlR5rdGdsFvJ0KdI em0hKgHRORprpZ88/HqUtvcZF8KzKxOeT9OOThZuA5iprhNP X-Google-Smtp-Source: ABdhPJxRWlAS3Y7o99bz2NRZOWqyWZUdFi5jkgeq4aEYy6wgyoHmAKIczSEVOOAbIii8xhb3f/OqEKwMGCLl4m6qdZs= X-Received: by 2002:a9d:7741:: with SMTP id t1mr9020028otl.368.1596569565392; Tue, 04 Aug 2020 12:32:45 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: <20200804185313.GT92412@kduck.mit.edu> From: Warren Parad Date: Tue, 4 Aug 2020 21:32:34 +0200 Message-ID: To: Benjamin Kaduk Cc: Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ce0f3805ac1251c4" Archived-At: Subject: Re: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 19:32:48 -0000 --000000000000ce0f3805ac1251c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that is fundamentally part of the question: > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues. Food for thought. - Warren Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: > Hi Denis, > > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > > > > Since you replied in parallel, I will make a response similar to the on= e > > I sent to Dick. > > > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in use h= ere. What > > > you describe as RS2, which might in fact be an RS unto itself, is a > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client of= RS1/. What you > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, b= ut it is not at > > > all the same as an OAuth client. I appreciate your mapping of the > > > entities below, but it makes it difficult to hold a discussion if we > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we ca= n define > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new def= initions, > > > but we=E2=80=99ve got a chance to be more precise with how we define = things. > > > > In the ISO context, each document must define its own terminology. The > > boiler plate for RFCs does not mandate a terminology or definitions > section > > but does not prevent it either. The vocabulary is limited and as long a= s > > we clearly define what our terms are meaning, we can re-use a term > already > > used in another RFC. This is also the ISO approach. > > Just because we can do something does not necessarily mean that it is a > good idea to do so. We are clear that we are producing a protocol that i= s > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted Dick = to > use the term "GS" in XAuth, picking a name that was not already used in > OAuth 2.0. > > -Ben > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ce0f3805ac1251c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that is fundamentally part of the question:
We are clear that we = are producing a protocol that is
conceptually (if not more strongly) rel= ated to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different d= efinitions may lead to unnecessary
confusion

=
If we say that this document assumes OAuth2.0 terminology, then we sho= uld not change the meanings of any definition. If we are saying this supers= edes or replaces what OAuth 2.0 creates, then we should pick the best word = for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of= first hand experience of industries "ruining words", and attempt= ing to side-step the problem rather than redefining the word just confuses = everyone as everyone forgets the original meaning as new documents come out= , but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

=

= W= arren Parad

Founder, CTO

Secure = your user data and complete your authorization architecture. Implement=C2= =A0Authress.
<= /div>


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ce0f3805ac1251c4-- From nobody Tue Aug 4 16:15:53 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 5CF653A111B for ; Tue, 4 Aug 2020 16:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Au8xmvLdcx0v for ; Tue, 4 Aug 2020 16:15:50 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 521343A1119 for ; Tue, 4 Aug 2020 16:15:50 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id p13so7297079ilh.4 for ; Tue, 04 Aug 2020 16:15:50 -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=ex04AsWaUeEYKvNXLn0L1AsjOjljPXJerVvX/cbtE6k=; b=RF9WJo5bs3YWeOZRhyaTM3Ue4zT8euSEGb5QN2C78RAW3wXtYgRong7dt2A0ppl9QM NUJoUow1AtNrRkaDAQu9HkBq7cw+gMpuI2Xy5VbBI3b+eNRqIHyGHJqxrEEiHuobqCiF O1ntj7r7d4JIYqDBcnjow7VKk733WBqXKlauLxxHNEsOFnqmXydyqjhlBFWHMi/zCUa8 UNohZjxt4We3emWiHb6G1jiXWS9Uwxw3ylO1IQpBvFLHI7QjCojbIZyAcMnsVO7wqW1z irsh173kx2PN04l/RGkM4x8mRsjISYTnH5R4ZElKxjQUkRoI++fKE2mexU0X6MrMLRwT oYrw== 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=ex04AsWaUeEYKvNXLn0L1AsjOjljPXJerVvX/cbtE6k=; b=BktJOkmV+NGFkAiKgw7fd3ZRdZ3JgV/1k2YlVIwA8BcEeHEoJzCDT41zUW15zURSFy YEHfQuLTXpCwXDQjxxG79IVUeUAcN+r+IpSonXaF97UHTIzXmFKJybsU2Z//eD+EDKup D/Ubppv18HYjlLG43b2zKYbxJOb6qDUNvpQ8OA088qrDCUciIkS26yOmuCBPdWOE8L/h dpW6WZ5iUfx4i2HIHAtBE508/fEMmL1V1Q+1YfC09ziekLAtNT/T5kjpRrQG53LWRouV yFiXJ2HPtDx2lekfDUPBOH7y003fhY3zhOWz8zCdI7nRT1Bfa+gNO8otXiStv6z2W46s yghQ== X-Gm-Message-State: AOAM533N/3t/Y8Usa+98SBK89ZNrxb08xcQfvVqTHmTF1xs3h+mHD8vs H6IOeR7EDA8fIP3227gEolgW2Pi6nyjfUzmnQRk= X-Google-Smtp-Source: ABdhPJxj3l2xhordXsV6Nw6CpJ7FZ0kmCbyWv3vCvqqBaZYgNZFGw6riJk4zKlaHdT6ZURhsDbks0fv9aavy/yf7S94= X-Received: by 2002:a92:d781:: with SMTP id d1mr826386iln.68.1596582949646; Tue, 04 Aug 2020 16:15:49 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 5 Aug 2020 01:15:37 +0200 Message-ID: To: Warren Parad Cc: Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009175e205ac156fd7" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 04 Aug 2020 23:15:52 -0000 --0000000000009175e205ac156fd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 on making necessary changes. Keeping the status quo is a good idea only if it fits with the new purpose of the work. Based on what we learned from years of experience, I think we should be open to revising the terminology. Fabien Le mar. 4 ao=C3=BBt 2020 =C3=A0 21:32, Warren Parad a = =C3=A9crit : > I think that is fundamentally part of the question: > >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion > > > If we say that this document assumes OAuth2.0 terminology, then we should > not change the meanings of any definition. If we are saying this supersed= es > or replaces what OAuth 2.0 creates, then we should pick the best word for > the job and ignore conflicting meanings from OAuth 2.0. I have a lot of > first hand experience of industries "ruining words", and attempting to > side-step the problem rather than redefining the word just confuses > everyone as everyone forgets the original meaning as new documents come > out, but the confusion with the use of a non-obvious word continues. > > Food for thought. > - Warren > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: > >> Hi Denis, >> >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> > >> > Since you replied in parallel, I will make a response similar to the >> one >> > I sent to Dick. >> > >> > > Hi Denis, >> > > >> > > I think there=E2=80=99s still a problem with the terminology in use = here. >> What >> > > you describe as RS2, which might in fact be an RS unto itself, is a >> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client o= f RS1/. What you >> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, = but it is not at >> > > all the same as an OAuth client. I appreciate your mapping of the >> > > entities below, but it makes it difficult to hold a discussion if we >> > > aren=E2=80=99t using the same terms. >> > > >> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we c= an define >> > > our own terms. The bad news is that this is really hard to do. >> > > >> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >> definitions, >> > > but we=E2=80=99ve got a chance to be more precise with how we define= things. >> > >> > In the ISO context, each document must define its own terminology. The >> > boiler plate for RFCs does not mandate a terminology or definitions >> section >> > but does not prevent it either. The vocabulary is limited and as long >> as >> > we clearly define what our terms are meaning, we can re-use a term >> already >> > used in another RFC. This is also the ISO approach. >> >> Just because we can do something does not necessarily mean that it is a >> good idea to do so. We are clear that we are producing a protocol that = is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion. If I understand correctly, a similar reasoning prompted Dick >> to >> use the term "GS" in XAuth, picking a name that was not already used in >> OAuth 2.0. >> >> -Ben >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000009175e205ac156fd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on making necessary changes. Keeping the status quo is= a good idea only if it fits with the new purpose of the work. Based on wha= t we learned from years of experience, I think we should be open to revisin= g the terminology.=C2=A0

Fabien=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">Le mar. 4 ao=C3=BBt 2020 =C3=A0 21:32,= Warren Parad <wparad@rhosys.ch&= gt; a =C3=A9crit=C2=A0:
I think that is fundamentally part of the question:
We are clear that we are produci= ng a protocol that is
conceptually (if not more strongly) related to OAu= th 2.0, and reusing terms
from OAuth 2.0 but with different definitions = may lead to unnecessary
confusion

If we = say that this document assumes OAuth2.0 terminology, then we should not cha= nge the meanings of any definition. If we are saying this supersedes or rep= laces what OAuth 2.0 creates, then we should pick the best word for the job= and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand= experience of industries "ruining words", and attempting to side= -step the problem rather than redefining the word just confuses everyone as= everyone forgets the original meaning as new documents come out, but the c= onfusion with the use of a non-obvious word continues.

=
Food for thought.
- Warren

=

Warren Parad

Founder, CTO

Secure your user data and complete your auth= orization architecture. Implement=C2=A0Auth= ress.

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:<= br>
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000009175e205ac156fd7-- From nobody Wed Aug 5 02:26:31 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 D515E3A13D8 for ; Wed, 5 Aug 2020 02:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uCwwLAstEfM9 for ; Wed, 5 Aug 2020 02:26:27 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6A33A13D3 for ; Wed, 5 Aug 2020 02:26:26 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d03 with ME id BlSP230062bcEcA03lSPdy; Wed, 05 Aug 2020 11:26:24 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 05 Aug 2020 11:26:24 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: <722214c8-59f6-ec8e-f4d1-f77682cceb52@free.fr> From: Denis Message-ID: <358820c8-0df0-bf8d-4aaa-c60106b06a5f@free.fr> Date: Wed, 5 Aug 2020 11:26:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E456B2AA523274B1AF609020" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 05 Aug 2020 09:26:30 -0000 This is a multi-part message in MIME format. --------------E456B2AA523274B1AF609020 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Dick, > Denis > > I don't think it is productive to redefine terms that are well understood. From the discussion, it is obvious that the terms we want to use are not well defined, hence they can't be well understood. If we were drafting an ISO standard, we would need to apply the ISO rules from the ISO/IEC Directives Part 2 [1] , called "Part 2 : Rules for the structure and drafting of International Standards". 16.5.6    Definitions The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop. A definition shall not take the form of, or contain, a requirement. For OAuth, the word "client" is used in section 1.1 (Roles) from RFC 6749 with the following explanation. client       An application making protected resource requests on behalf of the resource owner and with its authorization.       [Other explanations follow ... ] This explanation may be adequate in the context of OAuth but is clearly not compatible with the meaning of a client role in a client-server model, since it relates to a "resource owner" which is a concept that does not necessarily exist in a client-server model. Since we want to focus on a User that is using a client application to interact with the outside elements of the model, hereafter are two proposals: client application: application by means of which a user interacts with RS(s) and AS(s) user agent: application by means of which a user interactswith RS(s) and AS(s) Note: I don't like that much "Resource Client" since it concatenates two contradictory terms. > "The Client connects to the printing service (RS2) and the User > authenticates to the printing service (RS2)" > > Does not answer the question of how the User authenticates to the RS. > This implies the user has an account at RS2. It does answer to the question. As clearly explained, the User must have or must create an account at RS2: "This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account and that the prints can be sent to a known address". As also clearly mentioned :"Any authentication method supported by RS1 or RS2 can be used by the User". > If that is the case, it is not just acting in the role of a resource > server. Your sentence does not allow to understand what you mean by "it". You will notice that I answered to all your questions. However, I raised the two following questions which were left answered: **Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ? Maybe you should take these questions in a more general sense: How would you solve the photo sharing example now ? What would be the full scenario ? What about the Privacy Considerations for such a solution ? Denis [1] https://www.iso.org/sites/directives/current/part2/index.xhtml > > /Dick > > ᐧ > > On Tue, Aug 4, 2020 at 2:28 AM Denis > wrote: > > Hi Dick, > >> Hi Denis >> >> In your proposed flow, how does RS2 know who the user is that it >> is dealing with? > > The response is in the text: "The Client connects to the printing > service (RS2) and the User authenticates to the printing service > (RS2)". > >> In OAuth, the AS authenticates the User for the RS. In the photo >> sharing example, the AS and RS are from the same organization, so >> the AS knowing what the RS was doing was not an issue. > > Nevertheless, a full description is still missing and might help > to better understand the privacy issues. > >> What you call a Client is not an OAuth Client, but is more of an >> agent for the User. > > RFC 6749 states: > > In OAuth, the client requests access to resources controlled > by the resource owner and hosted by the resource server, > and is issued a different set of credentials than those of the > resource owner. > > This is how I use the term client which fits with the > Client-Server model. > > However, RFC 6749 also states in section 1.1 (Roles) : > > client >       An application making protected resource requests on > behalf of the resource owner and with its authorization. > > This is clearly not how I use the term client. > > The term "User Agent" might grasp the concept, but I clearly like > better the term "Client", > as long as we define the use of this term in the context of GNAP. > > Denis > >> Microsoft InfoCards comes to mind as a comparable architecture, >> and it seems aligned with what Tom is asking for. >> >> >> >> >> >> On Mon, Aug 3, 2020 at 12:35 AM Denis > > wrote: >> >> Hello Dick, >> >> This is a follow-up of the thread: "Reviewing >> draft-hardt-xauth-protocol-11". >> >> Hereafter are three exchanges between you and me which >> triggered this new thread: >> >> [Dick]    The photo sharing example was a driving use >> case for the creation of OAuth. >> [Denis]  We would need to revisit the original scenario >> and consider if it can be addressed in a different way >> than the original way. >> [Dick]   The use case is the same. Is there a different >> solution you are proposing ? >> >> My response is : Yes indeed, I have a different solution to >> address the same use case. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >> >> For example, an end-user (resource owner) can grant a >> printing service (client) access to her protected photos >> stored at >> a photo-sharing service (resource server), without >> sharing her username and password with the printing >> service. Instead, >> she authenticates directly with a server trusted by the >> photo-sharing service (authorization server), which >> issues the printing >> service delegation-specific credentials (access token). >> >> There are no further explanations. >> >> Which information will be disclosed by the resource owner to >> the authorization server to get "the printing service >> delegation-specific credentials" >> is not described. It is a private agreement between the AS >> and the RS. It is more than likely that the authorization >> server will learn information >> about which operation the resource owner is wishing to >> perform and where. Since in OAuth, the access token is >> supposed to be opaque to the Client, >> the user will be unable to make sure that her instructions >> have been carefully followed. >> >> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common >> point: they do not contain a "Privacy Considerations" section. >> Thus, the leakage of information to the AS is not discussed. >> >> It is possible to revisit the original scenario by applying >> "Privacy by design" principles. >> >> The scenario can be solved by using an old data transfer >> method that has been first described 32 years ago under the name >> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few >> years later in ISO/IEC 10740-2:1993. >> >> RDT allows two servers to directly exchange large amounts of >> data under the supervision of a client by communicating, >> through the client, >> a reference generated by one server to the other server. RDT >> does not use any Authorization Server (AS). This means that >> no AS is able >> to act as Big Brother and this solves a major privacy concern. >> * >> The three entities involved >> * >> The Client supporting a User (was the Resource Owner). >> The Photo-sharing service (was the Resource Server) : RS1. >> The Printing service (was the client): RS2. >> * >> * >> >> *Flow of operations with the Photo-sharing service (RS1) >> >> *The Client first connects to the photo-sharing service (RS1) >> and the User authenticates to the photo-sharing service (RS1). >> >> RS1 to User: "Please select the operation to be performed". >> Operation selected: "Print pictures using a third party >> printing service". >> >> RS1 to User: "Please select a set of pictures to be printed". >> The User selects the pictures. >> >> RS 1 User consent: "Do you agree RS1 to communicate your >> selection of pictures to a third party printing service" ? >> If the User consents, RS1 to Client: "Here is the reference >> to be used by your printing service to get the selected >> pictures". >> * >> Flow of operations with the Printing service* (*RS2) >> * >> The Client connects to the printing service (RS2) and the >> User authenticates to the printing service (RS2). >> >> _Note_: This allows to make sure that the user has an account >> on RS2 so that further operations can be charged to this account >>                       and that the prints can be sent to a >> known address. >> >> RS2 to User: "Please select the operation to be performed". >> Operation : "Print pictures to be received from a >> photo-sharing service ". >> RS2 to User: "Please indicate your photo-sharing service". >> The User responds: RS1. >> >> "Please enter the reference to be used by RS2 to receive the >> set of pictures from RS1". >> The Client (or the User) enters the reference generated by RS1. >> >> RS2 contacts RS1 using that reference in order to get the >> characteristics and the thumbnails of the pictures to be >> printed (i.e. not yet the whole pictures). >> >> RS2 to client: What are your printing preferences for each >> picture (e.g. number of prints, size, quality of the paper, >> resolution, margins, colours, etc... ) ? >> The User responds to all these questions. >> >> RS 2 User consent: This operation will be charged XX € ? Do >> you agree ? >> If the payment needs to be done on-line, then a payment phase >> is inserted. >> * >> Continuation of the flow of operations >> >> *Final message from RS1 to the Client: "Your selection of >> pictures will be soon transmitted to RS2". >> Final message from RS2 to the Client: "Your prints will be >> soon on their way". >> >> RS2 to RS1 (asynchronous): transmit the set of pictures >> corresponding to this reference. >> * >> Some of the advantages of RDT* >> >> 1. An end-user can grant a printing service (RS2) access to >> her protected photos stored at a photo-sharing service (RS1), >> without sharing her username and password with the >> printing service. >> 2. Neither RS1, nor RS2 need to use or to trust any AS. This >> solves the Big Brother privacy issue. >> 3. Any authentication method supported by RS1 or RS2 can be >> used by the User. >> 4. The User can use any photo-sharing service (RS1) with any >> printing service (RS2), as long as they both support RDT. >> 5. The User consent is first performed with the >> photo-sharing service (RS1) and then after with the >> printing service (RS2). >> 6. The reference generated by RS1 will only be accepted by >> RS1 during a time period. >> 7. The reference generated by RS1 allows RS2 to query first >> the thumbnails and then after the pictures selected by >> the User at RS1. >> 8. The data transfer of the pictures selected at RS1 by the >> User is performed asynchronously from RS1 to RS2 as a >> back-office operation. >> >> *Questions*: What would be the full scenario of this use case >> using OAuth ? What about Privacy Considerations ? >> >> Denis >> > --------------E456B2AA523274B1AF609020 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Dick,
Denis

I don't think it is productive to redefine terms that are well understood.

From the discussion, it is obvious that the terms we want to use are not well defined, hence they can't be well understood.

If we were drafting an ISO standard, we would need to apply the ISO rules from the ISO/IEC Directives Part 2 [1] ,
called "Part 2 : Rules for the structure and drafting of International Standards".

16.5.6    Definitions

The definition shall be written in such a form that it can replace the term in its context.
It shall not start with an article (“the”, “a”) nor end with a full stop.
A definition shall not take the form of, or contain, a requirement.

For OAuth, the word "client" is used in section 1.1 (Roles) from RFC 6749 with the following explanation.

client
      An application making protected resource requests on behalf of the resource owner and with its authorization.
      [Other explanations follow ... ]

This explanation may be adequate in the context of OAuth but is clearly not compatible with the meaning of a client role
in a client-server model, since it relates to a "resource owner" which is a concept that does not necessarily exist in a
client-server model.

Since we want to focus on a User that is using a client application to interact with the outside elements of the model, hereafter
are two proposals:

client application: application by means of which a user interacts with RS(s) and AS(s)

user agent: application by means of which a user interacts with RS(s) and AS(s)

Note: I don't like that much "Resource Client" since it concatenates two contradictory terms.

"The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)"

Does not answer the question of how the User authenticates to the RS. This implies the user has an account at RS2.

It does answer to the question. As clearly explained, the User must have or must create an account at RS2: "This allows to make
sure that the user has an account on RS2 so that further operations can be charged to this account and that the prints can be sent
to a known address". As also clearly mentioned :"Any authentication method supported by RS1 or RS2 can be used by the User".

If that is the case, it is not just acting in the role of a resource server.

Your sentence does not allow to understand what you mean by "it".

You will notice that I answered to all your questions. However, I raised the two following questions which were left answered:

        Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Maybe you should take these questions in a more general sense:

How would you solve the photo sharing example now ? What would be the full scenario ?
What about the Privacy Considerations for such a solution ?

Denis

[1] https://www.iso.org/sites/directives/current/part2/index.xhtml


/Dick

ᐧ

On Tue, Aug 4, 2020 at 2:28 AM Denis <denis.ietf@free.fr> wrote:
Hi Dick,

Hi Denis

In your proposed flow, how does RS2 know who the user is that it is dealing with?

The response is in the text: "The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)".

In OAuth, the AS authenticates the User for the RS. In the photo sharing example, the AS and RS are from the same organization, so the AS knowing what the RS was doing was not an issue.

Nevertheless, a full description is still missing and might help to better understand the privacy issues.

What you call a Client is not an OAuth Client, but is more of an agent for the User.

RFC 6749 states:

In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server,
and is issued a different set of credentials than those of the resource owner.

This is how I use the term client which fits with the Client-Server model.

However, RFC 6749 also states in section 1.1 (Roles) :

client
      An application making protected resource requests on behalf of the resource owner and with its authorization.

This is clearly not how I use the term client.

The term "User Agent" might grasp the concept, but I clearly like better the term "Client",
as long as we define the use of this term in the context of GNAP.

Denis

Microsoft InfoCards comes to mind as a comparable architecture, and it seems aligned with what Tom is asking for.





On Mon, Aug 3, 2020 at 12:35 AM Denis <denis.ietf@free.fr> wrote:

Hello Dick,

This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]    The photo sharing example was a driving use case for the creation of OAuth.
[Denis]  We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
[Dick]   The use case is the same. Is there a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed. 

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principles.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

            Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
                      and that the prints can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX € ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
  3. Any authentication method supported by RS1 or RS2 can be used by the User.
  4. The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis



--------------E456B2AA523274B1AF609020-- From nobody Wed Aug 5 08:20:21 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 6D1103A0AC4 for ; Wed, 5 Aug 2020 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MlsGp3uBKsws for ; Wed, 5 Aug 2020 08:20:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE823A0ABA for ; Wed, 5 Aug 2020 08:20:16 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 075FKDNn022189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 5 Aug 2020 11:20:13 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BDE4F4F0-5A40-4B78-A07C-0BE297E98BA7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 5 Aug 2020 11:20:13 -0400 In-Reply-To: Cc: Benjamin Kaduk , Denis , "txauth@ietf.org" To: Warren Parad References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 05 Aug 2020 15:20:19 -0000 --Apple-Mail=_BDE4F4F0-5A40-4B78-A07C-0BE297E98BA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is ignore the fact that GNAP is going to be coming up in a world that = is already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! =E2=80=94 Justin > On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >=20 > I think that is fundamentally part of the question: > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion >=20 > If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >=20 > Food for thought. > - Warren >=20 >=20 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 >=20 > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: > Hi Denis, >=20 > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > >=20 > > Since you replied in parallel, I will make a response similar to the = one=20 > > I sent to Dick. > >=20 > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 > > > you describe as RS2, which might in fact be an RS unto itself, is = a=20 > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you=20 > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 > > > all the same as an OAuth client. I appreciate your mapping of the=20= > > > entities below, but it makes it difficult to hold a discussion if = we=20 > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can define=20 > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions,=20 > > > but we=E2=80=99ve got a chance to be more precise with how we = define things. > >=20 > > In the ISO context, each document must define its own terminology. = The=20 > > boiler plate for RFCs does not mandate a terminology or definitions = section > > but does not prevent it either. The vocabulary is limited and as = long as=20 > > we clearly define what our terms are meaning, we can re-use a term = already > > used in another RFC. This is also the ISO approach. >=20 > Just because we can do something does not necessarily mean that it is = a > good idea to do so. We are clear that we are producing a protocol = that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted = Dick to > use the term "GS" in XAuth, picking a name that was not already used = in > OAuth 2.0. >=20 > -Ben >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_BDE4F4F0-5A40-4B78-A07C-0BE297E98BA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m in favor of coming up with a new term that=E2=80=99s a better fit, = but I=E2=80=99m not really in favor of taking an existing term and = applying a completely new definition to it. In other words, I would = sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, more = specific and accurate term for the role than to define =E2=80=9Cclient=E2=80= =9D as meaning something completely different. We did this in going from = OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 = doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does = it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifies = it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource = Server=E2=80=9D.

GNAP = can do something similar, in my opinion. But what we can=E2=80=99t do is = ignore the fact that GNAP is going to be coming up in a world that is = already permeated  by OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance!

 =E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> = wrote:

I think that is = fundamentally part of the question:
We are clear that we are producing a = protocol that is
conceptually (if not more strongly) = related to OAuth 2.0, and reusing terms
from OAuth 2.0 but = with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, = then we should not change the meanings of any definition. If we are = saying this supersedes or replaces what OAuth 2.0 creates, then we = should pick the best word for the job and ignore conflicting meanings = from OAuth 2.0. I have a lot of first hand experience of industries = "ruining words", and attempting to side-step the problem rather than = redefining the word just confuses everyone as everyone forgets the = original meaning as new documents come out, but the confusion with the = use of a non-obvious word continues.

Food for thought.
- = Warren

Warren Parad
Founder, = CTO
Secure your user data and = complete your authorization architecture. Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin = Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

= --Apple-Mail=_BDE4F4F0-5A40-4B78-A07C-0BE297E98BA7-- From nobody Wed Aug 5 17:59:51 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 234303A0B4C for ; Wed, 5 Aug 2020 17:59:45 -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 VASJFqVIs0Hd for ; Wed, 5 Aug 2020 17:59:41 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 438AB3A0AE5 for ; Wed, 5 Aug 2020 17:59:41 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 140so25238550lfi.5 for ; Wed, 05 Aug 2020 17:59:41 -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=Re5H6gS52TOP8cUolYn8XU4AURQW/E2ucDRgdkAIvPA=; b=XUVCLS5r8bgn2iZwLy8uKvDvDE4UWy7keO+x1cdcfTuz2x61TYPASNC1d0nR8CuJFt sy4VySA6ufJgPz9WhFxoJw0ui1CSdg2FW31ZdgvzBXmj5S9fqoTuJGKxVdLJH6lyDSzt Q6TAzWUgeiBpA2JGU7IL8sV6HF+ZRg76ZQCKjUHMzr33HCo/L8iyG+EtR6HnL2lPGa0u 6hTnAIYNvLmY4AB0udQ7l+c+DdcCbKvdptn60dwPFWh50MBa6SQrEVVOupjSiELVT7ie fEwPqWZOv0u2Y1LEzOn0GlSurupIuqLpl+bc/kecckmom27BIHqabFybOLMxt+wDa7GI 8W2A== 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=Re5H6gS52TOP8cUolYn8XU4AURQW/E2ucDRgdkAIvPA=; b=Jsxpvpa3PileWtrQ1RAOlpN25zYlnFtCJOLsGymglm5dZBH3TKYwreF0gJuKYm6X+p MLKODdrINutxtbMx6v/C/qRm9XidlJBkougiojl7Bb/R6+rIHqxdQxARIHEwX86JLYW1 fqvpyPSQlZyTCXyLSAcKwSydFn7O6OMOI5PZ+EyV/t5cT7xnilipiDFcJnqfPlajbK5l lzkI0nlT0CnJLaALFzAB6VPlXN4V+FhAuxYtrPfiCJRnCJBUNlJcZnxQk9kbYoB944Lz iNybyyZstRtFpF0EThpI7kUhOUHwjUXo+f2eV83I8OoAISAnzvKNB/3T6Ewuzy9rL9pe OkTA== X-Gm-Message-State: AOAM53271sx4dR1aEXsI5Zg9i30k3lGBOD6Fikho3wF2gaUsQekOXX// QFaSmHPoB+E4MoFYUo+CmzqyOfe87T3mhb6RtbE= X-Google-Smtp-Source: ABdhPJwEPny1HAkxsJa/L2k0pqTAJEiS6Z045s3+1gAk3iQvbY1iRu7MzI0n3ZV0lTdzPw/SaywCBx0HcTVLMPxm1Nw= X-Received: by 2002:a19:70c:: with SMTP id 12mr2753410lfh.207.1596675579124; Wed, 05 Aug 2020 17:59:39 -0700 (PDT) MIME-Version: 1.0 References: <722214c8-59f6-ec8e-f4d1-f77682cceb52@free.fr> <358820c8-0df0-bf8d-4aaa-c60106b06a5f@free.fr> In-Reply-To: <358820c8-0df0-bf8d-4aaa-c60106b06a5f@free.fr> From: Dick Hardt Date: Wed, 5 Aug 2020 17:59:03 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b7235305ac2b00cb" Archived-At: Subject: Re: [GNAP] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 06 Aug 2020 00:59:48 -0000 --000000000000b7235305ac2b00cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis Thanks for the clarification. Please note that the terms Client, AS, RS are the roles an entity plays. It is confusing when you say the User authenticates at RS2, as that is not an action that a RS performs. I'd suggest just using the entity and say what it does initially, and then we can indicate when an entity changes roles. Using OAuth 2.0 terms, the photo printing site is the Client, and the photo storage site is both the RS and the AS. You are adding a new role, which you are calling "Client", but it is not the OAuth Client role. It seems to be an "agent" of some kind that acts on behalf of the User to coordinate / orchestrate sharing information. It is unclear what value the "agent" plays in the flow you are proposing. =E1=90=A7 On Wed, Aug 5, 2020 at 2:26 AM Denis wrote: > Hello Dick, > > Denis > > I don't think it is productive to redefine terms that are well understood= . > > From the discussion, it is obvious that the terms we want to use are not > well defined, hence they can't be well understood. > > If we were drafting an ISO standard, we would need to apply the ISO rules > from the ISO/IEC Directives Part 2 [1] , > called "Part 2 : Rules for the structure and drafting of International > Standards". > > 16.5.6 Definitions > > The definition shall be written in such a form that it can replace the > term in its context. > It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2= =80=9D) nor end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > For OAuth, the word "client" is used in section 1.1 (Roles) from RFC 6749 > with the following explanation. > > client > An application making protected resource requests on behalf of the > resource owner and with its authorization. > [Other explanations follow ... ] > > This explanation may be adequate in the context of OAuth but is clearly > not compatible with the meaning of a client role > in a client-server model, since it relates to a "resource owner" which is > a concept that does not necessarily exist in a > client-server model. > > Since we want to focus on a User that is using a client application to > interact with the outside elements of the model, hereafter > are two proposals: > > client application: application by means of which a user interacts with > RS(s) and AS(s) > > user agent: application by means of which a user interacts with RS(s) and > AS(s) > > Note: I don't like that much "Resource Client" since it concatenates two = contradictory > terms. > > "The Client connects to the printing service (RS2) and the User > authenticates to the printing service (RS2)" > > Does not answer the question of how the User authenticates to the RS. Thi= s > implies the user has an account at RS2. > > It does answer to the question. As clearly explained, the User must have > or must create an account at RS2: "This allows to make > sure that the user has an account on RS2 so that further operations can b= e > charged to this account and that the prints can be sent > to a known address". As also clearly mentioned :"Any authentication metho= d > supported by RS1 or RS2 can be used by the User". > > If that is the case, it is not just acting in the role of a resource > server. > > Your sentence does not allow to understand what you mean by "it". > > You will notice that I answered to all your questions. However, I raised > the two following questions which were left answered: > > Questions: What would be the full scenario of this use case using > OAuth ? What about Privacy Considerations ? > > Maybe you should take these questions in a more general sense: > > How would you solve the photo sharing example now ? What would be the > full scenario ? > What about the Privacy Considerations for such a solution ? > > Denis > > [1] https://www.iso.org/sites/directives/current/part2/index.xhtml > > > /Dick > > =E1=90=A7 > > On Tue, Aug 4, 2020 at 2:28 AM Denis wrote: > >> Hi Dick, >> >> Hi Denis >> >> In your proposed flow, how does RS2 know who the user is that it is >> dealing with? >> >> The response is in the text: "The Client connects to the printing servic= e >> (RS2) and the User authenticates to the printing service (RS2)". >> >> In OAuth, the AS authenticates the User for the RS. In the photo sharing >> example, the AS and RS are from the same organization, so the AS >> knowing what the RS was doing was not an issue. >> >> Nevertheless, a full description is still missing and might help to >> better understand the privacy issues. >> >> What you call a Client is not an OAuth Client, but is more of an agent >> for the User. >> >> RFC 6749 states: >> >> In OAuth, the client requests access to resources controlled by the >> resource owner and hosted by the resource server, >> and is issued a different set of credentials than those of the resource >> owner. >> >> This is how I use the term client which fits with the Client-Server mode= l. >> >> However, RFC 6749 also states in section 1.1 (Roles) : >> >> client >> An application making protected resource requests on behalf of the >> resource owner and with its authorization. >> >> This is clearly not how I use the term client. >> >> The term "User Agent" might grasp the concept, but I clearly like better >> the term "Client", >> as long as we define the use of this term in the context of GNAP. >> Denis >> >> Microsoft InfoCards comes to mind as a comparable architecture, and it >> seems aligned with what Tom is asking for. >> >> >> >> >> >> On Mon, Aug 3, 2020 at 12:35 AM Denis wrote: >> >>> Hello Dick, >>> >>> This is a follow-up of the thread: "Reviewing >>> draft-hardt-xauth-protocol-11". >>> >>> Hereafter are three exchanges between you and me which triggered this >>> new thread: >>> >>> [Dick] The photo sharing example was a driving use case for the >>> creation of OAuth. >>> [Denis] We would need to revisit the original scenario and consider if >>> it can be addressed in a different way than the original way. >>> [Dick] The use case is the same. Is there a different solution you ar= e >>> proposing ? >>> >>> My response is : Yes indeed, I have a different solution to address the >>> same use case. >>> >>> RFC 6749 and draft-ietf-oauth-v2-1-00 both state: >>> >>> For example, an end-user (resource owner) can grant a printing service >>> (client) access to her protected photos stored at >>> a photo-sharing service (resource server), without sharing her username >>> and password with the printing service. Instead, >>> she authenticates directly with a server trusted by the photo-sharing >>> service (authorization server), which issues the printing >>> service delegation-specific credentials (access token). >>> >>> There are no further explanations. >>> >>> Which information will be disclosed by the resource owner to the >>> authorization server to get "the printing service delegation-specific >>> credentials" >>> is not described. It is a private agreement between the AS and the RS. >>> It is more than likely that the authorization server will learn informa= tion >>> about which operation the resource owner is wishing to perform and >>> where. Since in OAuth, the access token is supposed to be opaque to the >>> Client, >>> the user will be unable to make sure that her instructions have been >>> carefully followed. >>> >>> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they d= o >>> not contain a "Privacy Considerations" section. >>> Thus, the leakage of information to the AS is not discussed. >>> >>> It is possible to revisit the original scenario by applying "Privacy by >>> design" principles. >>> >>> The scenario can be solved by using an old data transfer method that ha= s >>> been first described 32 years ago under the name >>> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years >>> later in ISO/IEC 10740-2:1993. >>> >>> RDT allows two servers to directly exchange large amounts of data under >>> the supervision of a client by communicating, through the client, >>> a reference generated by one server to the other server. RDT does not >>> use any Authorization Server (AS). This means that no AS is able >>> to act as Big Brother and this solves a major privacy concern. >>> >>> >>> * The three entities involved * >>> The Client supporting a User (was the Resource Owner). >>> The Photo-sharing service (was the Resource Server) : RS1. >>> The Printing service (was the client): RS2. >>> >>> >>> >>> *Flow of operations with the Photo-sharing service (RS1) *The Client >>> first connects to the photo-sharing service (RS1) and the User >>> authenticates to the photo-sharing service (RS1). >>> >>> RS1 to User: "Please select the operation to be performed". >>> Operation selected: "Print pictures using a third party printing >>> service". >>> >>> RS1 to User: "Please select a set of pictures to be printed". >>> The User selects the pictures. >>> >>> RS 1 User consent: "Do you agree RS1 to communicate your selection of >>> pictures to a third party printing service" ? >>> If the User consents, RS1 to Client: "Here is the reference to be used >>> by your printing service to get the selected pictures". >>> >>> * Flow of operations with the Printing service* ( >>> *RS2) * >>> The Client connects to the printing service (RS2) and the User >>> authenticates to the printing service (RS2). >>> >>> *Note*: This allows to make sure that the user has an >>> account on RS2 so that further operations can be charged to this accoun= t >>> and that the prints can be sent to a known addres= s. >>> >>> RS2 to User: "Please select the operation to be performed". >>> Operation : "Print pictures to be received from a photo-sharing service >>> ". >>> RS2 to User: "Please indicate your photo-sharing service". >>> The User responds: RS1. >>> >>> "Please enter the reference to be used by RS2 to receive the set of >>> pictures from RS1". >>> The Client (or the User) enters the reference generated by RS1. >>> >>> RS2 contacts RS1 using that reference in order to get the >>> characteristics and the thumbnails of the pictures to be printed (i.e. >>> not yet the whole pictures). >>> >>> RS2 to client: What are your printing preferences for each picture (e.g= . >>> number of prints, size, quality of the paper, resolution, margins, colo= urs, >>> etc... ) ? >>> The User responds to all these questions. >>> >>> RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do you= agree ? >>> If the payment needs to be done on-line, then a payment phase is >>> inserted. >>> >>> >>> >>> * Continuation of the flow of operations *Final message from RS1 to the >>> Client: "Your selection of pictures will be soon transmitted to RS2". >>> Final message from RS2 to the Client: "Your prints will be soon on >>> their way". >>> >>> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding t= o >>> this reference. >>> >>> * Some of the advantages of RDT* >>> >>> 1. An end-user can grant a printing service (RS2) access to her >>> protected photos stored at a photo-sharing service (RS1), >>> without sharing her username and password with the printing service. >>> 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves >>> the Big Brother privacy issue. >>> 3. Any authentication method supported by RS1 or RS2 can be used by >>> the User. >>> 4. The User can use any photo-sharing service (RS1) with any >>> printing service (RS2), as long as they both support RDT. >>> 5. The User consent is first performed with the photo-sharing >>> service (RS1) and then after with the printing service (RS2). >>> 6. The reference generated by RS1 will only be accepted by RS1 >>> during a time period. >>> 7. The reference generated by RS1 allows RS2 to query first the >>> thumbnails and then after the pictures selected by the User at RS1. >>> 8. The data transfer of the pictures selected at RS1 by the User is >>> performed asynchronously from RS1 to RS2 as a back-office operation. >>> >>> *Questions*: What would be the full scenario of this use case using >>> OAuth ? What about Privacy Considerations ? >>> >>> Denis >>> >> >> > --000000000000b7235305ac2b00cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis

Thanks for the clarification. = Please note that the terms Client, AS, RS are the roles an entity plays. It= is confusing when you say the User authenticates at RS2, as that is not an= action that a RS performs. I'd suggest just using the entity and say w= hat it does initially, and then we can indicate when an entity changes role= s.

Using OAuth 2.0 terms, the=C2=A0photo printing = site is the Client, and the photo=C2=A0storage site is both the RS and the = AS.

You are adding a new role, which you are calli= ng "Client", but it is not the OAuth Client role. It seems to be = an "agent" of some kind that acts on behalf of the User to coordi= nate / orchestrate sharing information.

It is uncl= ear what value the "agent" plays in the flow you are proposing.


3D""=E1=90=A7

=
On Wed, Au= g 5, 2020 at 2:26 AM Denis <denis.= ietf@free.fr> wrote:
=20 =20 =20
Hello Dick,
=20
Denis

I don't think it is productive to redefine terms that are well understood.

From the discussion, it is obvious that the terms we want to use are not well defined, hence they can't be well understood.

If we were drafting an ISO standard, we would need to apply the ISO rules from the ISO/IEC Directives Part 2 [1] ,
called "Part 2 : Rules for the structure and drafting of International Standards".

16.5.6=C2=A0=C2=A0=C2=A0 Definitions

The definition shall be written in such a form that it can replace the term in its context.
It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80= =9Ca=E2=80=9D) nor end with a full stop.
A definition shall not take the form of, or contain, a requirement.

For OAuth, the word "client" is used = in section 1.1 (Roles) from RFC 6749 with the following explanation.

client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An application making protected re= source requests on behalf of the resource owner and with its authorization.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Other explanations follow ... ]

This explanation may be adequate in the context of OAuth but is clearly not compatible with the meaning of a client role
in a client-server model, since it relates to a "resource owne= r" which is a concept that does not necessarily exist in a
client-server model.

Since we want to focus on a User that is using a client application to interact with the outside elements of the model, hereafter
are two proposals:

client application: application by means of which a user interacts with RS(s) and AS(s)

user agent: applicatio= n = by means of which a user interacts with RS(s) and AS(s)

Note: I don't like that much "Resource Client" since it concatenates two <= /font>contradictory terms.

"The Client connects to th= e printing service (RS2) and the User authenticates to the printing service (RS2)"

Does not answer the question of how the User authenticates to the RS. This implies the user has an account=C2=A0at RS2.

It does answer to the question. As clearly explained, the User must have or must create an account at RS2: "This allows to make
sure that the user has an account on RS2 so that further operations can be charged to this account and that the prints can be sent
to a known address". As also clearly mentioned :"Any authentication method supported by RS1 or RS2 can be used by the User".

If that is the case, it is not just acting in the role of a resource server.

Your sentence does not allow to understand what you mean by "it".

You will notice that I answered to all your questions. However, I raised the two following questions which were left answered:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Maybe you should take these questions in a more general sense:

How would you solve the photo sharing example now ? <= font face=3D"Arial">What would be the full scenario ?
Wh= at about the Privacy Considerations for such a solution ?

Denis

[1] h= ttps://www.iso.org/sites/directives/current/part2/index.xhtml


/Dick

3D""==E1=90=A7

On Tue, Aug 4, 2020 at 2:28 A= M Denis <denis.ietf@free.fr> wrote:
Hi Dick,

Hi Denis

In your proposed flow, how does RS2 know who the user is that it is dealing with?

The response is in the text: "The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2)".

In OAuth, the AS authenticates the User for the=C2=A0R= S. In the photo sharing example, the AS and RS are from the same organization, so the AS knowing=C2=A0what the RS was doing was not an issue.

Nevertheless, a full description is still missing and might help to better understand the privacy issues.

What you call a Client is not an OAuth Client, but is more of an agent for the User.

RFC 6749 states:

In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server,
and is issued a different set of credentials than those of the resource owner.

This is how I use the term client which fits with the Client-Server model.

However, RFC 6749 also states in section 1.1 (Roles) :

client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An application making protec= ted resource requests on behalf of the resource owner and with its authorization.

This is clearly not how I use the term client.

The term "User Agent" might grasp the concept, but= I clearly like better the term "Client",
as long as we define the use of this term in the context of GNAP.

Denis

Microsoft InfoCards comes to mind as a comparable architecture, and it seems aligned with what Tom is asking for.





On Mon, Aug 3, 2020 a= t 12:35 AM Denis <denis.ietf@free.fr> wrote:

Hello Dick,

This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11"= .

Hereafter are three exchanges between you and me which triggered this new thread:

[Dick]=C2=A0=C2=A0=C2=A0 The photo sharing exampl= e was a driving use case for the creation of OAuth.
[Denis]=C2=A0 We would need to revisit the origin= al scenario and consider if it can be addressed in a different way than the original way.
[Dick]=C2=A0=C2=A0 The use case is the same. Is t= here a different solution you are proposing ?

My response is : Yes indeed, I have a different solution to address the same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at
a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead,
she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing
service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials"
is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client,
the user will be unable to make sure that her instructions have been carefully followed.=C2=A0
RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by design" principle= s.

The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-= 131 (1988) and a few years later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.

The three entities involved

The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.

Flow of operations with the Photo-sharing service (RS1)

The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).

RS1 to User:= "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures = to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a = third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".

Flow of operations with the Printing service (RS2)

The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No= te: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= and that the prints can be sent to a known address.

RS2 to User: "Please select the operation to b= e performed".
Operation : "Print pictures to be received fro= m a photo-sharing service ".
RS2 to User: "Please indicate your photo-shari= ng service".
The User responds: RS1.

"Please enter the reference to be used by RS2 = to receive the set of pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails= of the pictures to be printed (i.e. not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX =E2=82=AC ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.

Continuation of the flow of operations

Final message from RS1 to the Client: "You= r selection of pictures will be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon <= /span>on their way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.

Some of the advantages of RDT

  1. = An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
  2. = Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.=
  3. = Any authentication method supported by RS1 or RS2 can be used by the User.
  4. = The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
  5. = The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
  6. = The reference generated by RS1 will only be accepted by RS1 during a time period.
  7. = The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
  8. = The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.

Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?

Denis



--000000000000b7235305ac2b00cb-- From nobody Wed Aug 5 18:05:45 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 82E453A0B10 for ; Wed, 5 Aug 2020 18:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 XWdq_aIc1Ien for ; Wed, 5 Aug 2020 18:05:41 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 E63043A0B0A for ; Wed, 5 Aug 2020 18:05:40 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id h19so49837175ljg.13 for ; Wed, 05 Aug 2020 18:05:40 -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=/s5mn7L5vGWaEp/u2IJXsXOWKkVehn66iXfizfzlmGk=; b=HtRYFVg/M7Z7u4trtwkl4uoKsyiqgPspGj9zoTmT4OXXSRuf1t4Tq4D6QZs24XGfhI BtgtIrg06snMq2XHLb/DoFhlwRk8y5tYDrpCLCaf+gO3fj4QGvVMdEfuRLR9eWCKNMSd bpW0RaywsHKjDMTbPvsUlO36TTWMx0NuMP3eizwZ3aHjhB3DPINw8gpHpDzmAlKCGkMG s1mj8Rchzi/c8bnkMzC7a43/D4H8ue5nPSP2SQ8gEhvjerbOSY+EFKXNhO6k1dgumXcg 3ufD/Ezg2lA3AHlMbcFXd6Rw7rrWZHrL2ByuMCSqIIIoKTsX/KbU80F5B4Ps9Vc6P7jy Efmw== 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=/s5mn7L5vGWaEp/u2IJXsXOWKkVehn66iXfizfzlmGk=; b=BThhPZghImFDTWLy+FfpAAThb/5VJC4MxJxjXHUh3djLjubhva9TSMGuzf31Xoy3uH 2XbKHfumWU4k2qw9UdxifI6khG77LD1Z64sKRHGT4qKot4Y4BmtwYINkpEFgRFFjbL6R hZtoyq7YgABre7tzlzekqEJRGs8P8y2qJXSIxAlfl2ww4sOniEk6oICJUTFF2F9q8/ks HnEjbL8dqwUfuGCEJZ3//mxHLxWQvC4MVif3nAnfMs1hzLoUGd3CMmYR3Xu7B+n0Yg0q T/DjshdSlbUPYMgjLP7DawPA7vv2msPizMiJRXLVMh2JQMMy38VoWwZgyqwdL9GQYDL6 vK8w== X-Gm-Message-State: AOAM530MQmQ3q0i55EK7uQHqmQMiY1lYl48g0hQ4Aj300LN1UAvbzxb7 qheTwLCMMf6AWw5ud11Lh9dPGJT6AVBMHkvlNHQ= X-Google-Smtp-Source: ABdhPJzybX/DTtCD7y5dAna+GcL0dUbgmFTp5jNzL7QgsbDfKkjkV8vfXg0ubrarTmUhwt+s94JJ4HkcoOwq/E5dgek= X-Received: by 2002:a2e:2283:: with SMTP id i125mr2413970lji.142.1596675938849; Wed, 05 Aug 2020 18:05:38 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Dick Hardt Date: Wed, 5 Aug 2020 18:05:02 -0700 Message-ID: To: Justin Richer Cc: Warren Parad , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002816ea05ac2b1658" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 06 Aug 2020 01:05:44 -0000 --0000000000002816ea05ac2b1658 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC. Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity". /Dick =E1=90=A7 On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better= fit, but I=E2=80=99m not > really in favor of taking an existing term and applying a completely new > definition to it. In other words, I would sooner stop using =E2=80=9Cclie= nt=E2=80=9D and > come up with a new, more specific and accurate term for the role than to > define =E2=80=9Cclient=E2=80=9D as meaning something completely different= . We did this in > going from OAuth 1 to OAuth 2 already, moving from the even-more-confusin= g > =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, > nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qu= alifies it with > =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Server=E2=80= =9D. > > GNAP can do something similar, in my opinion. But what we can=E2=80=99t d= o is > ignore the fact that GNAP is going to be coming up in a world that is > already permeated by OAuth 2 and its terminology. We don=E2=80=99t have = a blank > slate to work with, but neither are we bound to use the same terms and > constructs as before. It=E2=80=99s going to be a delicate balance! > > =E2=80=94 Justin > > On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: > > I think that is fundamentally part of the question: > >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion > > > If we say that this document assumes OAuth2.0 terminology, then we should > not change the meanings of any definition. If we are saying this supersed= es > or replaces what OAuth 2.0 creates, then we should pick the best word for > the job and ignore conflicting meanings from OAuth 2.0. I have a lot of > first hand experience of industries "ruining words", and attempting to > side-step the problem rather than redefining the word just confuses > everyone as everyone forgets the original meaning as new documents come > out, but the confusion with the use of a non-obvious word continues. > > Food for thought. > - Warren > > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: > >> Hi Denis, >> >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> > >> > Since you replied in parallel, I will make a response similar to the >> one >> > I sent to Dick. >> > >> > > Hi Denis, >> > > >> > > I think there=E2=80=99s still a problem with the terminology in use = here. >> What >> > > you describe as RS2, which might in fact be an RS unto itself, is a >> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client o= f RS1/. What you >> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, = but it is not at >> > > all the same as an OAuth client. I appreciate your mapping of the >> > > entities below, but it makes it difficult to hold a discussion if we >> > > aren=E2=80=99t using the same terms. >> > > >> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we c= an define >> > > our own terms. The bad news is that this is really hard to do. >> > > >> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >> definitions, >> > > but we=E2=80=99ve got a chance to be more precise with how we define= things. >> > >> > In the ISO context, each document must define its own terminology. The >> > boiler plate for RFCs does not mandate a terminology or definitions >> section >> > but does not prevent it either. The vocabulary is limited and as long >> as >> > we clearly define what our terms are meaning, we can re-use a term >> already >> > used in another RFC. This is also the ISO approach. >> >> Just because we can do something does not necessarily mean that it is a >> good idea to do so. We are clear that we are producing a protocol that = is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion. If I understand correctly, a similar reasoning prompted Dick >> to >> use the term "GS" in XAuth, picking a name that was not already used in >> OAuth 2.0. >> >> -Ben >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000002816ea05ac2b1658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Justin. Redefining well used terms will lead = to significant confusion. If we have a different role than what we have had= in=C2=A0the past, then that role should have a name not being used already= in OAuth or OIDC.

Given what we have learned, and my ow= n experience explaining what a Client is, and is not, improving the definit= ion for Client could prove useful. I am not suggesting the term be redefine= d, but clarified.=C2=A0

For example, clarifying th= at a Client is a role an entity plays in the protocol, and that the same en= tity may play other roles at other times, or some other language to help di= fferentiate between "role" and "entity".

=
/Dick
3D""=E1=90=A7

On Wed, Aug 5, 2020 = at 8:20 AM Justin Richer <jricher@mit= .edu> wrote:
I=E2=80=99m in favor of comin= g up with a new term that=E2=80=99s a better fit, but I=E2=80=99m not reall= y in favor of taking an existing term and applying a completely new definit= ion to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80= =9D and come up with a new, more specific and accurate term for the role th= an to define =E2=80=9Cclient=E2=80=9D as meaning something completely diffe= rent. We did this in going from OAuth 1 to OAuth 2 already, moving from the= even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at al= l, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always q= ualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResour= ce Server=E2=80=9D.

GNAP can do something similar, in my= opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is goin= g to be coming up in a world that is already permeated =C2=A0by OAuth 2 and= its terminology. We don=E2=80=99t have a blank slate to work with, but nei= ther are we bound to use the same terms and constructs as before. It=E2=80= =99s going to be a delicate balance!

=C2=A0=E2=80= =94 Justin

On Aug 4,= 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing = a protocol that is
conceptually (if not more strongly) related to OAuth = 2.0, and reusing terms
from OAuth 2.0 but with different definitions may= lead to unnecessary
confusion

If we say= that this document assumes OAuth2.0 terminology, then we should not change= the meanings of any definition. If we are saying this supersedes or replac= es what OAuth 2.0 creates, then we should pick the best word for the job an= d ignore conflicting meanings from OAuth 2.0. I have a lot of first hand ex= perience of industries "ruining words", and attempting to side-st= ep the problem rather than redefining the word just confuses everyone as ev= eryone forgets the original meaning as new documents come out, but the conf= usion with the use of a non-obvious word continues.

Food for thought.
- Warren

Secure your user data and complete yo= ur authorization architecture. Implement=C2=A0Authress.


<= div class=3D"gmail_quote">
On Tue, Aug= 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000002816ea05ac2b1658-- From nobody Thu Aug 6 04:00:10 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 3EB6A3A10E6 for ; Thu, 6 Aug 2020 04:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 hvul7Djy3v4h for ; Thu, 6 Aug 2020 04:00:06 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6913A1030 for ; Thu, 6 Aug 2020 04:00:05 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d15 with ME id CB022300S2bcEcA03B02Y1; Thu, 06 Aug 2020 13:00:03 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 06 Aug 2020 13:00:03 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt , Justin Richer Cc: Benjamin Kaduk , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> From: Denis Message-ID: <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> Date: Thu, 6 Aug 2020 12:59:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DFF755399B049DC29CF25746" Content-Language: en-GB Archived-At: Subject: [GNAP] Terminology 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: Thu, 06 Aug 2020 11:00:08 -0000 This is a multi-part message in MIME format. --------------DFF755399B049DC29CF25746 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin and Dick, [Was:  "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"] So let us attempt to define new terms: *initiating application (IA)*: application by means of which a user initiates interactions with RS(s) and AS(s) In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as: Resource Owner (RO): entity capable of granting access to a protected resource I propose to replace it with Resource Manager (RM): *Resource Manager (RM)* : application or user that manages an access decision function of a Resource Server Denis > I agree with Justin. Redefining well used terms will lead to > significant confusion. If we have a different role than what we have > had in the past, then that role should have a name not being used > already in OAuth or OIDC. > > Given what we have learned, and my own experience explaining what a > Client is, and is not, improving the definition for Client could prove > useful. I am not suggesting the term be redefined, but clarified. > > For example, clarifying that a Client is a role an entity plays in the > protocol, and that the same entity may play other roles at other > times, or some other language to help differentiate between "role" and > "entity". > > /Dick > ᐧ > > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: > > I’m in favor of coming up with a new term that’s a better fit, but > I’m not really in favor of taking an existing term and applying a > completely new definition to it. In other words, I would sooner > stop using “client” and come up with a new, more specific and > accurate term for the role than to define “client” as meaning > something completely different. We did this in going from OAuth 1 > to OAuth 2 already, moving from the even-more-confusing “consumer” > to “client”, but OAuth 2 doesn’t use the term “consumer” at all, > nor does it use “server” on its own but instead always qualifies > it with “Authorization Server” and “Resource Server”. > > GNAP can do something similar, in my opinion. But what we can’t do > is ignore the fact that GNAP is going to be coming up in a world > that is already permeated  by OAuth 2 and its terminology. We > don’t have a blank slate to work with, but neither are we bound to > use the same terms and constructs as before. It’s going to be a > delicate balance! > >  — Justin > >> On Aug 4, 2020, at 3:32 PM, Warren Parad > > wrote: >> >> I think that is fundamentally part of the question: >> >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and >> reusing terms >> from OAuth 2.0 but with different definitions may lead to >> unnecessary >> confusion >> >> >> If we say that this document assumes OAuth2.0 terminology, then >> we should not change the meanings of any definition. If we are >> saying this supersedes or replaces what OAuth 2.0 creates, then >> we should pick the best word for the job and ignore conflicting >> meanings from OAuth 2.0. I have a lot of first hand experience of >> industries "ruining words", and attempting to side-step the >> problem rather than redefining the word just confuses everyone as >> everyone forgets the original meaning as new documents come out, >> but the confusion with the use of a non-obvious word continues. >> >> Food for thought. >> - Warren >> >> >> Warren Parad >> Founder, CTO >> >> Secure your user data and complete your authorization >> architecture. Implement Authress . >> >> >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > > wrote: >> >> Hi Denis, >> >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> > >> > Since you replied in parallel, I will make a response >> similar to the one >> > I sent to Dick. >> > >> > > Hi Denis, >> > > >> > > I think there’s still a problem with the terminology in >> use here. What >> > > you describe as RS2, which might in fact be an RS unto >> itself, is a >> > > “Client” in OAuth parlance because it is /a client of >> RS1/. What you >> > > call a “client” has no analogue in the OAuth world, but >> it is not at >> > > all the same as an OAuth client. I appreciate your >> mapping of the >> > > entities below, but it makes it difficult to hold a >> discussion if we >> > > aren’t using the same terms. >> > > >> > > The good news is that this isn’t OAuth, and as a new WG >> we can define >> > > our own terms. The bad news is that this is really hard >> to do. >> > > >> > > In GNAP, we shouldn’t just re-use existing terms with new >> definitions, >> > > but we’ve got a chance to be more precise with how we >> define things. >> > >> > In the ISO context, each document must define its own >> terminology. The >> > boiler plate for RFCs does not mandate a terminology or >> definitions section >> > but does not prevent it either. The vocabulary is limited >> and as long as >> > we clearly define what our terms are meaning, we can re-use >> a term already >> > used in another RFC. This is also the ISO approach. >> >> Just because we can do something does not necessarily mean >> that it is a >> good idea to do so.  We are clear that we are producing a >> protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and >> reusing terms >> from OAuth 2.0 but with different definitions may lead to >> unnecessary >> confusion.  If I understand correctly, a similar reasoning >> prompted Dick to >> use the term "GS" in XAuth, picking a name that was not >> already used in >> OAuth 2.0. >> >> -Ben >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------DFF755399B049DC29CF25746 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Justin and Dick,

[Was:  "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
Resource Owner (RO): entity capable of granting access to a protected resource
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit.edu> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

Warren Parad
Founder, CTO
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

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

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


--------------DFF755399B049DC29CF25746-- From nobody Thu Aug 6 04:49: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 D09583A0B41 for ; Thu, 6 Aug 2020 04:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 VW09clTqM0f1 for ; Thu, 6 Aug 2020 04:49:03 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 5483A3A0A5F for ; Thu, 6 Aug 2020 04:49:03 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id a5so33984948ioa.13 for ; Thu, 06 Aug 2020 04:49:03 -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=zVEHwad+HSEyGurgeo/pSvBE7+xuGvFUaXkqdL7SDB0=; b=iCoBSmQwahOebV5cXKriRl6b5WauNVrXDfCMRK4zHnxtWLG609Py18GYO98yvBRi7H CBtsdL1PrsApFB9Zkz7N1fgt+NNn3iSxy/BZuUsyW9tHnSHlIzZst+DE344xVjv0Ud9r II+Myd6d+G2a/gG1+fBf5BWbX89Tf4WXrB/v3oEXGhHgxei0figmVB3jGa/h1y2yrdNb oXFLGOOJWrtgsGqR4w7jq64aoeK+m4koq5N0BYGY4Uvqvm5U9Q4N93mPfFHH13HYzMFT eOx6B9ld6mUg9mtrCyWmk8dpSeCw9myX8Uk9ipKzvvbSkIXDR38gy8IZZEaSNi9f65N/ asrQ== 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=zVEHwad+HSEyGurgeo/pSvBE7+xuGvFUaXkqdL7SDB0=; b=tvXG1vkDEwRg+M16XAgnAebrtscOhL/gFtm26kPeurpykrgukCb5i+Mb7NnPsOpHg1 a30LXzUwr9jNkvZ31w5j1QxyuJCLjmBfjBXDbZEbQ6q1tz3o/kwjQT8NdlhXjdb+dyhl KwkRNa4vhucDxmX5Fe4+MssKgKonolzuYG+X52Ekki9/k58TQ6ug0ua2DoC0dRfWYnRg DWWstz2lrObJe2J9Jckt/29LI3XdDo1pZbPiM8vdN7zh8G/0fPpWsFo0bck6vKkDJHsK 2G8O0ZqEHgWMRJwcAsReV2YAt8RE1Wcdgd0m9uHEndbL16Cg9dOBYX6ACcy0Imt7JcPq So7Q== X-Gm-Message-State: AOAM532ux/0YjMudzWn1p63K6+h9uifVsOF3E3DmrbFMogC1l3E6s492 0JBOjH9E81FLdJitlwI2bN8/bl9Kx6RfF+LJ7BA= X-Google-Smtp-Source: ABdhPJz6nFQ/Yr81/Gk+caUXm6Y751OpMAYbcryIBaIcA0bZRPHiN1YSwWeWNGIyKd5wfApJtpkJEIPKZabitFpPL7c= X-Received: by 2002:a5d:8041:: with SMTP id b1mr9332639ior.74.1596714542574; Thu, 06 Aug 2020 04:49:02 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> In-Reply-To: <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> From: Fabien Imbault Date: Thu, 6 Aug 2020 13:48:51 +0200 Message-ID: To: Denis Cc: Dick Hardt , Justin Richer , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e2f6c05ac3413ee" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 06 Aug 2020 11:49:06 -0000 --0000000000001e2f6c05ac3413ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, To me, client has always been a strange word in the context of OAuth, as it has a meaning well defined both in everyday life (this client is a good customer) and in computer science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any teaching experience shows that it does make the concepts hard to grasp for a majority of (clever) people. As for the RO, previous discussions suggested Resource Controller (RC) also, which may be a bit more specific than manager. Fabien On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: > Justin and Dick, > > [Was: "Revisiting the photo sharing example (a driving use case for the > creation of OAuth)"] > > So let us attempt to define new terms: > > *initiating application (IA)*: application by means of which a user > initiates interactions with RS(s) and AS(s) > > In the same way, we should get rid of the term Resource Owner (RO), which > is currently defined as: > > Resource Owner (RO): entity capable of granting access to a protected > resource > > I propose to replace it with Resource Manager (RM): > > *Resource Manager (RM)* : application or user that manages an access > decision function of a Resource Server > > Denis > > I agree with Justin. Redefining well used terms will lead to significant > confusion. If we have a different role than what we have had in the past, > then that role should have a name not being used already in OAuth or OIDC= . > > Given what we have learned, and my own experience explaining what a Clien= t > is, and is not, improving the definition for Client could prove useful. I > am not suggesting the term be redefined, but clarified. > > For example, clarifying that a Client is a role an entity plays in the > protocol, and that the same entity may play other roles at other times, o= r > some other language to help differentiate between "role" and "entity". > > /Dick > =E1=90=A7 > > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: > >> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bette= r fit, but I=E2=80=99m >> not really in favor of taking an existing term and applying a completely >> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >> and come up with a new, more specific and accurate term for the role tha= n >> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diffe= rent. We did this >> in going from OAuth 1 to OAuth 2 already, moving from the >> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >> >> GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is >> ignore the fact that GNAP is going to be coming up in a world that is >> already permeated by OAuth 2 and its terminology. We don=E2=80=99t have= a blank >> slate to work with, but neither are we bound to use the same terms and >> constructs as before. It=E2=80=99s going to be a delicate balance! >> >> =E2=80=94 Justin >> >> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >> >> I think that is fundamentally part of the question: >> >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion >> >> >> If we say that this document assumes OAuth2.0 terminology, then we shoul= d >> not change the meanings of any definition. If we are saying this superse= des >> or replaces what OAuth 2.0 creates, then we should pick the best word fo= r >> the job and ignore conflicting meanings from OAuth 2.0. I have a lot of >> first hand experience of industries "ruining words", and attempting to >> side-step the problem rather than redefining the word just confuses >> everyone as everyone forgets the original meaning as new documents come >> out, but the confusion with the use of a non-obvious word continues. >> >> Food for thought. >> - Warren >> >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >> >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response similar to the >>> one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in use= here. >>> What >>> > > you describe as RS2, which might in fact be an RS unto itself, is a >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world,= but it is not at >>> > > all the same as an OAuth client. I appreciate your mapping of the >>> > > entities below, but it makes it difficult to hold a discussion if w= e >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can >>> define >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>> definitions, >>> > > but we=E2=80=99ve got a chance to be more precise with how we defin= e things. >>> > >>> > In the ISO context, each document must define its own terminology. Th= e >>> > boiler plate for RFCs does not mandate a terminology or definitions >>> section >>> > but does not prevent it either. The vocabulary is limited and as long >>> as >>> > we clearly define what our terms are meaning, we can re-use a term >>> already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily mean that it is a >>> good idea to do so. We are clear that we are producing a protocol that >>> is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted Dic= k >>> to >>> use the term "GS" in XAuth, picking a name that was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001e2f6c05ac3413ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

To me, client has always been= a strange word in the context of OAuth, as it has a meaning well defined b= oth in everyday life (this client is a good customer) and in computer scien= ce (client-server interaction). Thus I always have to make the mental trans= lation to the OAuth world before any discussion... And any teaching experie= nce shows that it does make the concepts hard to grasp for a majority of (c= lever) people.

As for the RO, previous discussions= suggested Resource Controller=C2=A0(RC)=C2=A0also, which may be a bit more= specific than manager.=C2=A0

Fabien=C2=A0

On= Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
Txauth mailing list
= Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000001e2f6c05ac3413ee-- From nobody Thu Aug 6 09:54:00 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 AEF193A0BE7 for ; Thu, 6 Aug 2020 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 0la7daL7G7_i for ; Thu, 6 Aug 2020 09:53:54 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 A47463A0B40 for ; Thu, 6 Aug 2020 09:53:53 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id i10so17802100ljn.2 for ; Thu, 06 Aug 2020 09:53:53 -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=qN1g8Gu9w++1Q67+yNrCcpRSBfPVL2syyX5PoXHCLcM=; b=a8pQS0/kV43Sr17hxnyhXHoAb4y+vutgdHRE/PSvn7GmSqgjg8J4B2CseVXEgJHsle Tr1L/KlQnIZZ9dROTel84lWx1F2Mj7e3hp+pV/hJS0mjloU6MwYyPc/U/pLbESIPUBXm 2OdMq9vh3Pi3KastVEE6tsboZ5FVApAuloUmhOlN0yTcXfjZBBt6l2+yvlVzdcUMxa7q 9M7o+aCgeqZJ3H6pYoN49CE+uphLOvxp3xaoXBpa2HeXWKZzuWS4eA3TbKRjOm7luxY3 IEPB9ixyUxEoVn93lSNgy8sYJE2kowbdD0fygEl5+9NaLNOmb6pY+9H3psOEBpUxoXPf XL6g== 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=qN1g8Gu9w++1Q67+yNrCcpRSBfPVL2syyX5PoXHCLcM=; b=sLtKOFWtYuGaZeZm1DwhFH/tkSknkS/BrhvRTJKUwmX3KxGzilTrwq7wa4u1FlPNv9 RUrqstkFmEgC345lo4bjEGRphDJeOkkZpGhGfkjCxm1yhATCEyCUTy/D9iagTKQjJ9KJ 7VwX7gvRR6Qsw65CSeAENceb7sJqKki6QjgGUvWGvnO7PcE8rYh3if88RY2lJKdnj2Nm OaHTwzA9yluDzGK/BNG2GwaXhLXAEl4l/etMPWNr88v52cs/7dV3GCGlqd/pI3lGqG07 SC05dIAX0es7sijzjV/9MdafY0hln5lh/+vH655SINik6Ps0ku/Pd5cUSheZU2J4T5dB FDIQ== X-Gm-Message-State: AOAM531tTne0oElFpIlQWPML/pG1JsyFKfcBGkpMdDFi0y8ytdDbofOw GdfA/PmnMDy7y1j30Js+7l3pM3M12GIyBO7rFmE= X-Google-Smtp-Source: ABdhPJyHCeOaNjBuXmRDD5pbmu4ZOfrLr7OYQIJlwlKV9UyKh8n9ig/Q3BPGdB1Hl9SForF41cDULNUVRQHnGpC3/04= X-Received: by 2002:a2e:865a:: with SMTP id i26mr4014786ljj.246.1596732831428; Thu, 06 Aug 2020 09:53:51 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> In-Reply-To: From: Dick Hardt Date: Thu, 6 Aug 2020 09:53:14 -0700 Message-ID: To: Fabien Imbault Cc: Denis , Justin Richer , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000037f70f05ac385516" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 06 Aug 2020 16:53:57 -0000 --00000000000037f70f05ac385516 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The term client in OAuth came from the computer science definition of client-server interaction. The client is getting an access token so it can call a server, specifically, a resource server (to differentiate it from the authorization server). The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context. =E1=90=A7 On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault wrote: > Hi, > > To me, client has always been a strange word in the context of OAuth, as > it has a meaning well defined both in everyday life (this client is a goo= d > customer) and in computer science (client-server interaction). Thus I > always have to make the mental translation to the OAuth world before any > discussion... And any teaching experience shows that it does make the > concepts hard to grasp for a majority of (clever) people. > > As for the RO, previous discussions suggested Resource > Controller (RC) also, which may be a bit more specific than manager. > > Fabien > > On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: > >> Justin and Dick, >> >> [Was: "Revisiting the photo sharing example (a driving use case for the >> creation of OAuth)"] >> >> So let us attempt to define new terms: >> >> *initiating application (IA)*: application by means of which a user >> initiates interactions with RS(s) and AS(s) >> >> In the same way, we should get rid of the term Resource Owner (RO), >> which is currently defined as: >> >> Resource Owner (RO): entity capable of granting access to a protected >> resource >> >> I propose to replace it with Resource Manager (RM): >> >> *Resource Manager (RM)* : application or user that manages an access >> decision function of a Resource Server >> >> Denis >> >> I agree with Justin. Redefining well used terms will lead to significant >> confusion. If we have a different role than what we have had in the past= , >> then that role should have a name not being used already in OAuth or OID= C. >> >> Given what we have learned, and my own experience explaining what a >> Client is, and is not, improving the definition for Client could prove >> useful. I am not suggesting the term be redefined, but clarified. >> >> For example, clarifying that a Client is a role an entity plays in the >> protocol, and that the same entity may play other roles at other times, = or >> some other language to help differentiate between "role" and "entity". >> >> /Dick >> =E1=90=A7 >> >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >> >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m >>> not really in favor of taking an existing term and applying a completel= y >>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>> and come up with a new, more specific and accurate term for the role th= an >>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diff= erent. We did this >>> in going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >>> >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is >>> ignore the fact that GNAP is going to be coming up in a world that is >>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t hav= e a blank >>> slate to work with, but neither are we bound to use the same terms and >>> constructs as before. It=E2=80=99s going to be a delicate balance! >>> >>> =E2=80=94 Justin >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>> >>> I think that is fundamentally part of the question: >>> >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion >>> >>> >>> If we say that this document assumes OAuth2.0 terminology, then we >>> should not change the meanings of any definition. If we are saying this >>> supersedes or replaces what OAuth 2.0 creates, then we should pick the = best >>> word for the job and ignore conflicting meanings from OAuth 2.0. I have= a >>> lot of first hand experience of industries "ruining words", and attempt= ing >>> to side-step the problem rather than redefining the word just confuses >>> everyone as everyone forgets the original meaning as new documents come >>> out, but the confusion with the use of a non-obvious word continues. >>> >>> Food for thought. >>> - Warren >>> >>> Warren Parad >>> Founder, CTO >>> Secure your user data and complete your authorization architecture. >>> Implement Authress . >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>> >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a response similar to the >>>> one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in us= e here. >>>> What >>>> > > you describe as RS2, which might in fact be an RS unto itself, is = a >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client= of RS1/. What >>>> you >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world= , but it is not >>>> at >>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>> > > entities below, but it makes it difficult to hold a discussion if >>>> we >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can >>>> define >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>> definitions, >>>> > > but we=E2=80=99ve got a chance to be more precise with how we defi= ne things. >>>> > >>>> > In the ISO context, each document must define its own terminology. >>>> The >>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>> section >>>> > but does not prevent it either. The vocabulary is limited and as lon= g >>>> as >>>> > we clearly define what our terms are meaning, we can re-use a term >>>> already >>>> > used in another RFC. This is also the ISO approach. >>>> >>>> Just because we can do something does not necessarily mean that it is = a >>>> good idea to do so. We are clear that we are producing a protocol tha= t >>>> is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted >>>> Dick to >>>> use the term "GS" in XAuth, picking a name that was not already used i= n >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000037f70f05ac385516 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The term client in OAuth came from the computer science de= finition of client-server interaction.

The client is get= ting an access token so it can call a server, specifically, a resource serv= er (to differentiate it from the authorization server).

The confusion in my experience usually stems from people working=C2= =A0with software=C2=A0that is acting in multiple=C2=A0roles. IE, the softwa= re=C2=A0that is acting as a client in once context, is also acting as an RS= in other contexts, or even acting as an AS. The other confusion is that pe= ople view clients as being the software the user is using -- although it ma= y not be acting as a client in the oauth context.

=

3D""=E1=90=A7

On Thu, Aug 6, 2020= at 4:49 AM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
Hi,=C2=A0

To me= , client has always been a strange word in the context of OAuth, as it has = a meaning well defined both in everyday life (this client is a good custome= r) and in computer science (client-server interaction). Thus I always have = to make the mental translation to the OAuth world before any discussion... = And any teaching experience shows that it does make the concepts hard to gr= asp for a majority of (clever) people.

As for the = RO, previous discussions suggested Resource Controller=C2=A0(RC)=C2=A0also,= which may be a bit more specific than manager.=C2=A0

<= div>Fabien=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wrot= e:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
Txauth mailing list
= Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000037f70f05ac385516-- From nobody Thu Aug 6 12:50:27 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 C21543A0E45 for ; Thu, 6 Aug 2020 12:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6l46VSpIfKCd for ; Thu, 6 Aug 2020 12:50:23 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E59C3A0E44 for ; Thu, 6 Aug 2020 12:50:22 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 076JoIq4024860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Aug 2020 15:50:18 -0400 From: Justin Richer Message-Id: <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_8ECF6E3A-D656-40A8-834B-DFF506A25A51" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 6 Aug 2020 15:50:17 -0400 In-Reply-To: Cc: Fabien Imbault , Denis , Benjamin Kaduk , "txauth@ietf.org" To: Dick Hardt References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 06 Aug 2020 19:50:26 -0000 --Apple-Mail=_8ECF6E3A-D656-40A8-834B-DFF506A25A51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >=20 > The term client in OAuth came from the computer science definition of = client-server interaction. This, I would argue, is exactly why it=E2=80=99s a bad label for = something that=E2=80=99s distinctly more specific in this context, and I = would love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth. =E2=80=94 Justin >=20 > The client is getting an access token so it can call a server, = specifically, a resource server (to differentiate it from the = authorization server). >=20 > The confusion in my experience usually stems from people working with = software that is acting in multiple roles. IE, the software that is = acting as a client in once context, is also acting as an RS in other = contexts, or even acting as an AS. The other confusion is that people = view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context. >=20 >=20 >=20 > =E1=90=A7 >=20 > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault = > wrote: > Hi,=20 >=20 > To me, client has always been a strange word in the context of OAuth, = as it has a meaning well defined both in everyday life (this client is a = good customer) and in computer science (client-server interaction). Thus = I always have to make the mental translation to the OAuth world before = any discussion... And any teaching experience shows that it does make = the concepts hard to grasp for a majority of (clever) people. >=20 > As for the RO, previous discussions suggested Resource Controller (RC) = also, which may be a bit more specific than manager.=20 >=20 > Fabien=20 >=20 > On Thu, Aug 6, 2020 at 1:00 PM Denis > wrote: > Justin and Dick, >=20 > [Was: "Revisiting the photo sharing example (a driving use case for = the creation of OAuth)"] >=20 > So let us attempt to define new terms: > initiating application (IA): application by means of which a user = initiates interactions with RS(s) and AS(s) > In the same way, we should get rid of the term Resource Owner (RO), = which is currently defined as: > Resource Owner (RO): entity capable of granting access to a protected = resource > I propose to replace it with Resource Manager (RM): > Resource Manager (RM) : application or user that manages an access = decision function of a Resource Server > Denis >=20 >> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>=20 >> Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>=20 >> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>=20 >> /Dick >> =E1=90=A7 >>=20 >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>=20 >> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>=20 >> =E2=80=94 Justin >>=20 >>> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>>=20 >>> I think that is fundamentally part of the question: >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>> confusion >>>=20 >>> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>>=20 >>> Food for thought. >>> - Warren >>>=20 >>>=20 >>> Warren Parad >>> Founder, CTO >>> Secure your user data and complete your authorization architecture. = Implement Authress . >>>=20 >>>=20 >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>> Hi Denis, >>>=20 >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> >=20 >>> > Since you replied in parallel, I will make a response similar to = the one=20 >>> > I sent to Dick. >>> >=20 >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >>> > > you describe as RS2, which might in fact be an RS unto itself, = is a=20 >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >>> > > all the same as an OAuth client. I appreciate your mapping of = the=20 >>> > > entities below, but it makes it difficult to hold a discussion = if we=20 >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,=20 >>> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >>> >=20 >>> > In the ISO context, each document must define its own terminology. = The=20 >>> > boiler plate for RFCs does not mandate a terminology or = definitions section >>> > but does not prevent it either. The vocabulary is limited and as = long as=20 >>> > we clearly define what our terms are meaning, we can re-use a term = already >>> > used in another RFC. This is also the ISO approach. >>>=20 >>> Just because we can do something does not necessarily mean that it = is a >>> good idea to do so. We are clear that we are producing a protocol = that is >>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted = Dick to >>> use the term "GS" in XAuth, picking a name that was not already used = in >>> OAuth 2.0. >>>=20 >>> -Ben >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_8ECF6E3A-D656-40A8-834B-DFF506A25A51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

The term client in OAuth came = from the computer science definition of client-server = interaction.

This, = I would argue, is exactly why it=E2=80=99s a bad label for something = that=E2=80=99s distinctly more specific in this context, and I would = love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.

 =E2=80=94 Justin


The client is getting an access token so it can call a = server, specifically, a resource server (to differentiate it from the = authorization server).

The confusion in my experience usually stems from people = working with software that is acting in multiple roles. = IE, the software that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The = other confusion is that people view clients as being the software the = user is using -- although it may not be acting as a client in the oauth = context.



3D""=E1=90=A7

On Thu, Aug = 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi, 

To me, client has always been a strange word in the context = of OAuth, as it has a meaning well defined both in everyday life (this = client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the = OAuth world before any discussion... And any teaching experience shows = that it does make the concepts hard to grasp for a majority of (clever) = people.

As for = the RO, previous discussions suggested Resource = Controller (RC) also, which may be a bit more specific than = manager. 

Fabien 

On Thu, Aug = 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin and Dick,

[Was:  = "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:
Resource Owner (RO): entity = capable of granting access to a protected = resource
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well = used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should = have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own = experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

For example, clarifying that a Client is a role = an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""=E1=90=A7

On Wed, Aug 5, 2020 at = 8:20 AM Justin Richer <jricher@mit.edu> wrote:
=
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99= m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with = a new, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely = different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to = =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always = qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource = Server=E2=80=9D.

GNAP can do something similar, in my = opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going = to be coming up in a world that is already permeated  by = OAuth 2 and its terminology. We don=E2=80=99t have a blank slate = to work with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate = balance!

 =E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren = Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally = part of the question:
We are clear that we are producing a protocol that = is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document = assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren Parad
Founder, = CTO
Secure your user data and complete your authorization architecture. = Implement Authress.


On Tue, = Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a = problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth = parlance because it is /a client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D = has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same = terms.
> >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just = re-use existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be = more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we = are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

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

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


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

= --Apple-Mail=_8ECF6E3A-D656-40A8-834B-DFF506A25A51-- From nobody Thu Aug 6 13:16:10 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 BC83C3A0EE5 for ; Thu, 6 Aug 2020 13:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 BLkzl0tefd8J for ; Thu, 6 Aug 2020 13:16:00 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 63AC03A0EDB for ; Thu, 6 Aug 2020 13:16:00 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id b22so18115062oic.8 for ; Thu, 06 Aug 2020 13:16:00 -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=yNGheCYYHjMm5w2JojAcN8ZPs48dPN2b44PgAoo89jY=; b=gHHhXGEYMWh2oYkD2PsD4zf9/5mNvvCEjQ8J6fXxNq+BlIjNzhioyPp6BavqK4Qk5m ORqUJZu78KrLFLLm/Zs3IWACg0XJbQXZJtD6D/8Jo6HJI1gUSJVCp9rLvew7UNtplXux kRVLcaQz7//Lr9D4lv78qxKmDyB0gjn5zHfaMocttmZ1BbLKXKDZhJ2kvz/8xTJQqzCd GGhI6JAIiOOqVprmp7RsguoPyeA9UmcA0byqtadW2RcmWWo3BmQThQhjn0ygyUU2iY3K zI7M0tJP60K0NL0xjZgIcH939eczJZV7STAthMpWw0S6p7k0hOYTCWmyDuo8r3PVapBG zEiw== 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=yNGheCYYHjMm5w2JojAcN8ZPs48dPN2b44PgAoo89jY=; b=XkkINC88eSPt8WWct1OBAOUDVF66Q31YHm0wEwB4x6MZRUcEjtbG11phblYI7/P6cV okGty9KFwvDl4c6VNWBdoemlB68ACJteBot/Db3XrUEZHTeNE/FFvJxjxs0uxK3WHiFm mDylwu9/MoYJgRJj6Pvrb/Vv3NA8q1tNOhT8VShlfeI+KNYmNUjeQewX7V6NAbrKSbwF X+H1YRQWsRrMDgi9DVgxTKnKrvQTF1PgehkNJD43Xeqq/8bqELazR155UHX1Uo3EAQWL Ta7SJKGePnT4eXg+0w4acQAg9da+SezxH+jG3AHPYfVwrnvngcMxiLSmO0742cA1SXAz 7ELg== X-Gm-Message-State: AOAM530IIEQYnbujHEjIZP4cEIGQcrUME/XIOpZ5a0FZtBuYivvCX7el fZ/VegrMOs40Q2ekD7WxnjLHNVcaqAClSZC8iT2DwQ== X-Google-Smtp-Source: ABdhPJw/6U9i9i236zLqhDGDFnTTQ3HdMJlTb721FraJpOi86vCryN98PqI0oHgEySLhu9PGJ2TrP5B8R1oZy+wRgH8= X-Received: by 2002:a54:448f:: with SMTP id v15mr8786366oiv.172.1596744959563; Thu, 06 Aug 2020 13:15:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Thu, 6 Aug 2020 13:15:48 -0700 Message-ID: To: Dick Hardt Cc: Kathleen Moriarty , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000001c999e05ac3b2890" Archived-At: Subject: Re: [GNAP] [Txauth] Kathleen's review 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: Thu, 06 Aug 2020 20:16:09 -0000 --0000000000001c999e05ac3b2890 Content-Type: text/plain; charset="UTF-8" the only encoding that i care about is jose-encoding. Without it the doc would just be advisory for my applications. Peace ..tom On Thu, Jul 30, 2020 at 1:36 PM Dick Hardt wrote: > (adding in a subject) > > Thanks for the clarification Kathleen! > > I fully agree with you that we want developers to think of security when > reviewing the document. > > Ironically, I wanted to ensure a Client developer knew they needed to > authenticate in all calls to the AS, and I had JOSE in every section in the > first drafts I sent to Justin for feedback, and he suggested I factor it > out into its own section, so that it would be easier to specify > other client authentication mechanisms such as MTLS and http signing. I > factored it into its own section, and then got feedback that people > preferred the JOSE client authentication to be a separate document. > > In the milestones for the WG[1], the core delegation protocol is a > milestone targeted for July 2021, and a key presentation mechanism is an > independent milestone targeted for Oct 2021. > > In the charter we have anticipated having numerous key presentation > mechanisms, so separating the key presentation documents from the core > protocol seemed the right choice. > > Q: Are you suggesting we combine the documents? Or is there a different > recommendation to overcome what you saw as a security deficiency in XAuth > vs XYZ? > > As you know, there is much more to security than cryptography, and I > considered how to encourage best practices in the design. One of those is > the separation of concerns, which I wanted to encourage by using URIs and > HTTP methods so that GS decomposition was straight forward per slides 11-13 > of my presentation [2]. > > In contrast to XYZ, XAuth requires the Grant URI and AZ URI to start with > the GS URI, so the Client has certainty on which GS a Grant or AZ is for on > receipt, and when working with the URIs later on. An opaque token or handle > stored in a database could be associated with any GS -- so a self > describing URI can assist in detecting an error in which GS it belongs to. > I think constraints like these improve security as more errors can be > detected, and attack vectors are reduced. > > btw: A GS could have just one entry point if desired, the GS URI, and the > Grant URI and AZ URI could be represented by query parameters. > > /Dick > > [1] https://datatracker.ietf.org/group/gnap/about/ > > [2] > https://www.ietf.org/proceedings/108/slides/slides-108-gnap-xauth-dick-hart-00 > > > Would you confirm you were looking at -13 of XAuth? (The datatracker tools > are confused and depending on how you land on the page, the latest version > is not displayed) > > In my first drafts that I shared offline with Justin, I had JOSE client > authentication throughout > > Put JOSE Client authentication into a separate document in version -08. > > WG deliverables -- authentication is a separate document. > > > > > From a security perspective, I focussed on the protocol aspects rather > than the security aspects. > > interaction modes > > URIs - based off of GS URI, methods and - decomposition > > client knows which GS a Grant or AZ came from > > > > > > > > > On Thu, Jul 30, 2020 at 8:11 AM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hey Dick, >> >> Thanks for your questions and all of your hard work. I'll respond inline >> as not to miss anything. >> >> On Wed, Jul 29, 2020 at 1:07 PM Dick Hardt wrote: >> >>> Hey Kathleen >>> >>> A couple questions on your presentation: >>> >>> 1) Which versions of the documents did you review? >>> >> Your last posted version to the datatracker. >> I had started with the latest in the datatracker for Justin, but switched >> when he announced the update. Although my skim on the datatracker one had >> similar impressions in terms of structure, ease of use, etc. >> >> >>> >>> 2) Would you elaborate on your security comparisons of XAuth and XYZ? I >>> want to make sure I understand the work you put into your review. While >>> reviewing your slides, I was not following a number of your statements. For >>> example: >>> >>> In your first slide: >>> >>> A) you stated that "XAuth Relies heavily on OAuth2.0, using Bearer token >>> and adding cryptographic (e.g.JOSE) functions after-the-fact". Both XAuth >>> and XYZ support bearer tokens for calling an RS. I'm not clear how this >>> feature is different in XAuth. >>> >> >> Sure, XAuth punts the use of security off in a section and is not more >> integrated in the approach. That's how OAUth is now and it's something >> that really should be fixed. Making it clear that security is an >> afterthought makes it an afterthought for developer and implementers. >> Industry is moving towards built-in intrinsic security. >> >> You can do this just as easily, but XYZ mentioned security in the >> flows/sequences as an inherent part of each. While it may not be perfect >> yet, the theme was there. The references to exchange of a key in section 2 >> and 3 with an editor note that this needs work are the first places the >> idea of embedding begins. >> >> The value generated in the access token doesn't explicitly use crypto, >> but could. This is something to consider. >> Section 4..4.2. - uses a HASH, but an HMAC or KMAC could be used. This >> is in the feedback I will be posting. >> >> Section 7 calls explicitly for use of a JWS and authorization values. >> >> Section 8 provides more explicit guidance for add-on, but it's not in a >> registry or another draft - part of this work. >> >> Section 13 points to the need for more work, acknowledging multiple ways >> to explore supporting security directly in the protocol. >> >> >> >> >> >>> B) What parts of XYZ did you view as "Builds security into the protocol >>> as opposed to adding it in later (e.g. OAuth2.0 bearer token + JWT)"? >>> >> See above. It's a lot more clear than the single reference in XAuth. >> >> >>> >>> C) "Interaction flows defined, focus more on security with cryptographic >>> requirements and examples included" -- there some cryptography in the >>> redirect flow, but not in the others. In my opinion, the cryptography in >>> the redirect flow does not add any value, and just complicates the >>> protocol. >>> >>> Perhaps you can point to sections in each draft? >>> >> See above. >> >> Best regards, >> Kathleen >> >> >>> >>> Thanks! >>> >>> /Dick >>> >>> >>> >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> >> -- >> >> Best regards, >> Kathleen >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001c999e05ac3b2890 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
the only encoding that i care about is jose-encoding. With= out it the doc would just be advisory for my applications.
Peace ..tom


On Th= u, Jul 30, 2020 at 1:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
(adding in a subject)=

Thanks for the clarificat= ion Kathleen!

I fully agree with you that we want develo= pers to think of security when reviewing the document.

=
Ironically, I wanted to ensure a Client developer knew they needed to = authenticate in all calls to the AS, and I had JOSE in every section in the= first drafts I sent to Justin for feedback, and he suggested I factor it o= ut into its own section,=C2=A0so that it would be easier to specify other= =C2=A0client authentication mechanisms such as MTLS and http signing. I fac= tored it into its own section, and then got feedback that people preferred = the JOSE client authentication to be a separate document.

In the milestones for the WG[1], the core delegation protocol is a = milestone targeted for July 2021, and a key presentation mechanism is an in= dependent milestone targeted for Oct 2021.

In the = charter we have anticipated having numerous key presentation mechanisms, so= separating the key presentation=C2=A0documents from the core protocol seem= ed the right choice.=C2=A0

Q: Are you suggesting w= e combine the documents? Or is there a different recommendation to overcome= what you saw as a security deficiency in XAuth vs XYZ?=C2=A0
As you know, there is much more to security than cryptography,= =C2=A0and I considered how to encourage best practices in the design. One o= f those is the separation of concerns, which I wanted to encourage by using= URIs and HTTP methods so that GS decomposition was straight forward per sl= ides 11-13 of my presentation=C2=A0[2].=C2=A0

In c= ontrast to XYZ, XAuth requires the=C2=A0Grant URI and AZ URI to start with = the=C2=A0GS URI, so the=C2=A0Client has certainty on which GS a Grant or AZ= is for on receipt, and when working with the URIs later on. An opaque toke= n or handle stored in a database could be associated with any GS -- so a se= lf describing URI can assist in detecting an error in which GS it belongs t= o. I think constraints like these improve security as more errors can be de= tected, and attack vectors are reduced.

btw: A GS = could have just one entry point if desired, the GS URI, and the Grant URI a= nd AZ URI could be represented by query parameters.

/Dick




Would you conf= irm you were looking at -13 of XAuth? (The datatracker tools are confused a= nd depending on how you land on the page, the latest version is not display= ed)

In my first drafts that I shared offline with = Justin, I had JOSE client authentication throughout

Put JOSE Client authentication into a separate document in version -08.

WG deliverables -- authentication is a separate doc= ument.




From a security=C2=A0perspective, I focussed on the protocol aspects rath= er than the security aspects.

interaction modes

URIs - based off of GS URI, methods and - decomposit= ion

client knows which GS a Grant or AZ came from<= /div>





<= /div>



On Thu, Jul 30, 2020 at 8:11 AM Kathleen= Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hey Dick,

Thanks for your questions and all of your hard work.= =C2=A0 I'll respond inline as not to miss anything.

On Wed, Jul 29, 2020= at 1:07 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Kathleen

A couple question= s on your presentation:

1) Which versions of the d= ocuments did you review?
You= r last posted version to the datatracker.
I had started with the = latest in the datatracker for Justin, but switched when he announced the up= date.=C2=A0 Although my skim on the datatracker one had similar impressions= in terms of structure, ease of use, etc.
=C2=A0

2) Would you elaborate = on your security comparisons of XAuth and XYZ? I want to make sure I unders= tand the=C2=A0work you put into your review.=C2=A0 While reviewing your sli= des, I was not following a number of your statements. For example:=C2=A0

In your first slide:

A) you= stated that "XAuth Relies heavily on OAuth2.0, using Bearer token and= adding cryptographic (e.g.JOSE) functions after-the-fact". Both XAuth= and XYZ support bearer tokens for calling an RS. I'm not clear how thi= s feature is different in XAuth.
=

Sure, XAuth punts the use of security off in a section = and is not more integrated in the approach.=C2=A0 That's how OAUth is n= ow and it's something that really should be fixed.=C2=A0 Making it clea= r that security is an afterthought makes it an afterthought for developer a= nd implementers.=C2=A0 Industry is moving towards built-in intrinsic securi= ty.

You can do this just as easily, but XYZ mentio= ned security in the flows/sequences as an inherent=C2=A0part of each.=C2=A0= =C2=A0While it may not be perfect yet, the theme was there.=C2=A0 The refe= rences to exchange of a key in section 2 and 3 with an editor note that thi= s needs work are the first places the idea of embedding begins.
<= br>
The value generated in the=C2=A0access token doesn't expl= icitly use crypto, but could.=C2=A0 This is something to consider.
Section 4..4.2. - uses a HASH, but an HMAC or KMAC could be used.=C2=A0 T= his is in the feedback I will be posting.

Section = 7 calls explicitly=C2=A0for use of a JWS and authorization values.

Section 8 provides more explicit guidance for add-on, but = it's not in a registry or another draft - part of this work.
=
Section 13 points to the need for more work, acknowledging= =C2=A0multiple ways to explore supporting security directly in the protocol= .





B) What parts of XYZ= did you view as "Builds security into the protocol as opposed to adding it in later (e.g. OAuth2.0 bearer token + JWT)"?=C2=A0
=
See above.=C2=A0 It's a lot more clear than the single reference i= n XAuth.
=C2=A0
<= div>
C) "Interaction flows defined, focus more on security with cryptographic requirements and examples included" -- there some cryptography=C2=A0in the redirect= flow, but not in the others. In my=C2=A0opinion, the cryptography in the r= edirect flow does not add any value, and just complicates the protocol.=C2= =A0

Perhaps you can point to sections in each draf= t?
See above.

=
Best regards,
Kathleen
=C2=A0
=

Thanks!
/Dick



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


--

Best regards,
Kathleen
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000001c999e05ac3b2890-- From nobody Thu Aug 6 15:36:35 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 483EA3A0A81 for ; Thu, 6 Aug 2020 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 P2idRpwzztPc for ; Thu, 6 Aug 2020 15:36:31 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 6CAE43A0A47 for ; Thu, 6 Aug 2020 15:36:30 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id m15so26274654lfp.7 for ; Thu, 06 Aug 2020 15:36:30 -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=uM4rclI/x/NeFRbSSIr/K9GmRTFYiBjD0csyxExHR7M=; b=H5eHY4ra68kAxKFJQh7RRFR260ALak3aShG2lHAoGVcBAoJeTPYCBvycz6zD3M4D66 DO7fHRr51a/fdygyM8CzTH60vT2gh3LyLlkCu+4KpAycqDHUITzVQz6TIadCl8fDCtWw ID1aKbq1WFUj62ujRv1waLhsOa+cPz+3SBzC+4QuOWO8lkHxRoz9SEimIVJJ5XarwV+d 0/Vn+eshK0Me6NRCYTiJrGbA9Bf0EyE4mJjOU+CqyptaujVPgFs14Ng8xl2LPLcogXAb V+YlGj3q3lbLIrRYtcMZNKEZWP5XmtmSTgWZFagAuBr6Tdr+Kpf+j5rYdcmLPukLSodE 9cdw== 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=uM4rclI/x/NeFRbSSIr/K9GmRTFYiBjD0csyxExHR7M=; b=jAitHxPxvJnB0jShO+q3AY0NItP4ws5K79De+ZqdS+DhWg6h82dkgHteJyWdB81r9o vplyoAaPEAuIahhXuQP3TfFGdP7wcYAFqgWrL4OeVjK8xV7OZYmrcHQbnYYu/WIsb9Un 0B+12j4lnlPdkg6znllqwMvek3fjIlsSC2ZMq6AwV8dRVl9/eYuFGk1/0xlohDO1Bb2z ViuxX3ffh8EVniVUyHvqQWsutUaplJ9kpCF8vkH2U0eGcJhpgrpp+BOcQ02PfAlrXxC8 LpuNTkPare4y3Fj6QL6iOQMj9N1lMEHcM+gvqeAAywm772TCeLfeRFSfsGle5phit++D q39w== X-Gm-Message-State: AOAM530/ceaAXm+1eODoy8gm9TvKEa8WoQPUswUZ06Gqi03ZvpgB7s1j phinbYKmXC8zu87GgUb2fyDNGnkl/BBiE1j9siE= X-Google-Smtp-Source: ABdhPJx++A+zDIjgYjAyR3xMfdnDW5gye3e2aClCoWaXbYU42ahKSrdEHCjEEeRAJlQcNj2bnxfc8nnL1twLWCj1UYo= X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr4861645lfp.23.1596753388373; Thu, 06 Aug 2020 15:36:28 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> In-Reply-To: <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> From: Dick Hardt Date: Thu, 6 Aug 2020 15:35:52 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008211a105ac3d1ef9" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 06 Aug 2020 22:36:34 -0000 --0000000000008211a105ac3d1ef9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still think that client was the right name in OAuth 2, as the client wanted to do a client-server interaction, so the client used OAuth 2 to get an access token to interact with the "server". I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC. /Dick =E1=90=A7 On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: > On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: > > > The term client in OAuth came from the computer science definition of > client-server interaction. > > > This, I would argue, is exactly why it=E2=80=99s a bad label for somethin= g that=E2=80=99s > distinctly more specific in this context, and I would love to see GNAP > adopt a more specific label for the role that we traditionally called > =E2=80=9Cclient=E2=80=9D in OAuth. > > =E2=80=94 Justin > > > The client is getting an access token so it can call a server, > specifically, a resource server (to differentiate it from the authorizati= on > server). > > The confusion in my experience usually stems from people working with > software that is acting in multiple roles. IE, the software that is actin= g > as a client in once context, is also acting as an RS in other contexts, o= r > even acting as an AS. The other confusion is that people view clients as > being the software the user is using -- although it may not be acting as = a > client in the oauth context. > > > > =E1=90=A7 > > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault > wrote: > >> Hi, >> >> To me, client has always been a strange word in the context of OAuth, as >> it has a meaning well defined both in everyday life (this client is a go= od >> customer) and in computer science (client-server interaction). Thus I >> always have to make the mental translation to the OAuth world before any >> discussion... And any teaching experience shows that it does make the >> concepts hard to grasp for a majority of (clever) people. >> >> As for the RO, previous discussions suggested Resource >> Controller (RC) also, which may be a bit more specific than manager. >> >> Fabien >> >> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >> >>> Justin and Dick, >>> >>> [Was: "Revisiting the photo sharing example (a driving use case for th= e >>> creation of OAuth)"] >>> >>> So let us attempt to define new terms: >>> >>> *initiating application (IA)*: application by means of which a user >>> initiates interactions with RS(s) and AS(s) >>> >>> In the same way, we should get rid of the term Resource Owner (RO), >>> which is currently defined as: >>> >>> Resource Owner (RO): entity capable of granting access to a protected >>> resource >>> >>> I propose to replace it with Resource Manager (RM): >>> >>> *Resource Manager (RM)* : application or user that manages an access >>> decision function of a Resource Server >>> >>> Denis >>> >>> I agree with Justin. Redefining well used terms will lead to significan= t >>> confusion. If we have a different role than what we have had in the pas= t, >>> then that role should have a name not being used already in OAuth or OI= DC. >>> >>> Given what we have learned, and my own experience explaining what a >>> Client is, and is not, improving the definition for Client could prove >>> useful. I am not suggesting the term be redefined, but clarified. >>> >>> For example, clarifying that a Client is a role an entity plays in the >>> protocol, and that the same entity may play other roles at other times,= or >>> some other language to help differentiate between "role" and "entity". >>> >>> /Dick >>> =E1=90=A7 >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>> >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bet= ter fit, but I=E2=80=99m >>>> not really in favor of taking an existing term and applying a complete= ly >>>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>>> and come up with a new, more specific and accurate term for the role t= han >>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely dif= ferent. We did this >>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserve= r=E2=80=9D on its own but instead >>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>> >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is >>>> ignore the fact that GNAP is going to be coming up in a world that is >>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t ha= ve a blank >>>> slate to work with, but neither are we bound to use the same terms and >>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>> >>>> I think that is fundamentally part of the question: >>>> >>>>> We are clear that we are producing a protocol that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion >>>> >>>> >>>> If we say that this document assumes OAuth2.0 terminology, then we >>>> should not change the meanings of any definition. If we are saying thi= s >>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the= best >>>> word for the job and ignore conflicting meanings from OAuth 2.0. I hav= e a >>>> lot of first hand experience of industries "ruining words", and attemp= ting >>>> to side-step the problem rather than redefining the word just confuses >>>> everyone as everyone forgets the original meaning as new documents com= e >>>> out, but the confusion with the use of a non-obvious word continues. >>>> >>>> Food for thought. >>>> - Warren >>>> >>>> Warren Parad >>>> Founder, CTO >>>> Secure your user data and complete your authorization architecture. >>>> Implement Authress . >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>> >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a response similar to th= e >>>>> one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there=E2=80=99s still a problem with the terminology in u= se here. >>>>> What >>>>> > > you describe as RS2, which might in fact be an RS unto itself, is >>>>> a >>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What >>>>> you >>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not >>>>> at >>>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>>> > > entities below, but it makes it difficult to hold a discussion if >>>>> we >>>>> > > aren=E2=80=99t using the same terms. >>>>> > > >>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can >>>>> define >>>>> > > our own terms. The bad news is that this is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>>> definitions, >>>>> > > but we=E2=80=99ve got a chance to be more precise with how we def= ine >>>>> things. >>>>> > >>>>> > In the ISO context, each document must define its own terminology. >>>>> The >>>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>>> section >>>>> > but does not prevent it either. The vocabulary is limited and as >>>>> long as >>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>> already >>>>> > used in another RFC. This is also the ISO approach. >>>>> >>>>> Just because we can do something does not necessarily mean that it is= a >>>>> good idea to do so. We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>> Dick to >>>>> use the term "GS" in XAuth, picking a name that was not already used = in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > --0000000000008211a105ac3d1ef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I still think that client was the right name in OAuth 2, a= s the client wanted to do a client-server interaction, so the client used O= Auth 2 to get an access token to interact with the "server".
<= div>
I do agree that it is not the best term in GNAP. Primari= ly because GNAP is a combination of the client from OAuth 2, and the relyin= g party from OIDC.=C2=A0

/Dick
3D""=E1=90=A7

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <jricher@mit.edu> wrote:
On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

The term client i= n OAuth came from the computer science definition of client-server interact= ion.

This, I would argue, is ex= actly why it=E2=80=99s a bad label for something that=E2=80=99s distinctly = more specific in this context, and I would love to see GNAP adopt a more sp= ecific label for the role that we traditionally called =E2=80=9Cclient=E2= =80=9D in OAuth.

=C2=A0=E2=80=94 Justin

<= blockquote type=3D"cite">

The clie= nt is getting an access token so it can call a server, specifically, a reso= urce server (to differentiate it from the authorization server).
=
The confusion in my experience usually stems from people wor= king=C2=A0with software=C2=A0that is acting in multiple=C2=A0roles. IE, the= software=C2=A0that is acting as a client in once context, is also acting a= s an RS in other contexts, or even acting as an AS. The other confusion is = that people view clients as being the software the user is using -- althoug= h it may not be acting as a client in the oauth context.



3D""=E1=90=A7
On Th= u, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
=
Hi= ,=C2=A0

To me, client has always been a strange word in = the context of OAuth, as it has a meaning well defined both in everyday lif= e (this client is a good customer) and in computer science (client-server i= nteraction). Thus I always have to make the mental translation to the OAuth= world before any discussion... And any teaching experience shows that it d= oes make the concepts hard to grasp for a majority of (clever) people.

As for the RO, previous discussions suggested Resource= Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific than mana= ger.=C2=A0

Fabien=C2=A0

On Thu, Aug 6, 2020 = at 1:00 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
Txauth mailing list
= Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

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


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

--0000000000008211a105ac3d1ef9-- From nobody Mon Aug 10 06:27:02 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 93FB13A1568 for ; Mon, 10 Aug 2020 06:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 EO1MZ_MPGb7B for ; Mon, 10 Aug 2020 06:26:59 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 437993A1566 for ; Mon, 10 Aug 2020 06:26:59 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id g14so8843841iom.0 for ; Mon, 10 Aug 2020 06:26: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=siOdo0VFhyJ4OT46iLp0ZDnb+kuHwEBUnMo4SPwIeSk=; b=k38/RzR9XbZXvlDgeZzh7GUUYcr7UtPFsPiU9kn41SmjtBo0lURwGH1hikgEz3wTIq Pvf+Ci0Gh++9NiBzjvAeyupxCna3DEDSy1K+xtQJnsGA3DklDNbTR8sMBJoK/vsW7DvH gTtfTaR+EEx5b18Yh5aBzUwahDNvOHN+AJyX6RYiA6n3XULBPW+myi9pna702Q8mGLZB XihZ3RC3vYEWaRfex8iRPcE7K8PURda9TIVdkDWi2DmtlDevNCELX8PH3m16T6LrztzE Fk7J9lfYD1utKVBPRl6QRizMNWq14T7V8dV7mVU2hHku5MvC/KR6YIw5wqQl+WVqrky6 y8RA== 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=siOdo0VFhyJ4OT46iLp0ZDnb+kuHwEBUnMo4SPwIeSk=; b=p3L4Z+t561mP34+rECeQ3fdRu1SD5Eex9q68wUuPJZy2wMBsXIEFJ7gF7ramOly72Q ZhiobaHw7tdXYUTocezNb36VjltVNf7Tk4IWmQuVfdg8madF81788z8wYUPr41xaq9cc Uibvs9YTmYTZyS0MojPkB+EiynN+mlOKtOTSJVIZBmLj/ARGQjPL2GUvN0+mukG2Ka+S 6nguN0gOk9e+MS8fB2G62WlLVBITS9e3rt3u2tUDQ89LYUrbOAFwXwLYF69n1iOZf+FF 3yod4eiDqYgcx6L1HdlIoJqanDoowMVh1qWAsT5Zhf7rL8TJXM5wdiAn1WsEJx0u8wt2 nOgw== X-Gm-Message-State: AOAM531bJzGZnGBl3tmQ+oj2txE9H0jglLcK2VSkGDZnrCPf6NB2i+sA Krj5RvBLuv4o1P51kT2I5rpJ8fCu/i2uQrJHcAM= X-Google-Smtp-Source: ABdhPJzIR0IMN6mJL5GzneRzEsDdWGz62JWdubdRB620sNtTpTILmhyXe8GjGaAy6NthYFCJSTIi0OQiAImdZhzjTOg= X-Received: by 2002:a6b:e31a:: with SMTP id u26mr16827273ioc.162.1597066018437; Mon, 10 Aug 2020 06:26:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 10 Aug 2020 15:26:47 +0200 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b6432a05ac85e882" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 10 Aug 2020 13:27:01 -0000 --000000000000b6432a05ac85e882 Content-Type: text/plain; charset="UTF-8" Thanks Denis for that proposal. I believe we can already implement most of your idea with https://github.com/ietf-wg-gnap/general/wiki/Modular-Interaction-Server. In particular, we can easily provide an interaction server that is chosen by the Client (which might be operated by the Client itself for instance, or by a party distinct from the AS). But for now, I'm still going through the AS, who knows what the tokens are used for. Your use case has the ability to change that. So, I'm trying to figure out how 6.2 would work, regarding RS hiding and the need for non opaque tokens. You're saying : "The choice of hiding or not hiding the true name of the RS is a choice made by the Client. Such a choice may be handled through a local configuration of the Client. If "privacy by default" is applied, hiding the true name of the RS should be the default choice. The role of the AS is to deliver the requested types of attributes into an access token without necessarily knowing to which RS(s) the access token is intended." So, after the interaction with the RO, suppose we get a list of tokens to mint (for instance in the format defined in XYZ), in this case we expect to generate token1: "token1": [ { "actions": [ "read" ], "locations": [ "https://server.example.net/" ], "datatypes": [ "metadata", "images" ] } ], As per rfc7523, the AS would then mint a JWT access token, including "aud":" https://server.example.net". Later the RS can check that the token has been generated with the right audience (amongst other things). Note that there's a proposal to provide more guidance on that topic https://github.com/ietf-wg-gnap/general/wiki/Directed-Access-Tokens. We can imagine it can soon become fairly complex. If I understand you well, you're suggesting an additional layer of indirection, in the form of alias to the locations url? Something in the form of: 1) The Client contacts the RS for information 2) The RS responds to the Client (including one-off aliases and their time to live) 3) The Client deals with consent (cf proposal related to the IS component), and the AS doesn't have to know what is asked 4) Based on what the RO consented, the AS is asked to mint token1, token2, etc. with aliases 5) The Client uses the aliased tokens with the RS I see the reason why you're suggesting that, but implementing that at scale may be tricky. I don't see how a local configuration of the client (as you suggest) is enough, you'll also need to share that information with the RS at some point. To work, the mapping between the Client and the RS would have to be private and probably even transient (if we can to avoid AS from scrawling RS endpoints for durable aliases, which would defeat the purpose), which pose questions of cache invalidation and the synchronicity with the token itself. Also you're saying (before step 5 occurs): "Once the Client has obtained the requested access tokens, they are not immediately presented to the RS: the Client should be able to verify that the content of each access token is in accordance with each access token request." I don't see the reason why the AS would present something else, especially if it has no notion what is actually requested to whom (if the previous scheme is effective). If we suppose we're asking for read access, maybe it could try a write access too, but for what use? The suggested verification scheme on the Client side supposes that the Client is honest anyway. If so, the Client would only use the token for a read request, so I don't understand which threat we're trying to avoid (except from something theorical). If the Client is dishonest, it won't care anyway. Am I over complexifying what you have in mind? Fabien On Tue, Aug 4, 2020 at 11:08 AM Denis wrote: > I tried my best twice to download three use cases in the Use cases > directory, but I failed. > > Rather than failing a third time, here is the direct link of the second > try: > > > https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) > > Denis > > > > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b6432a05ac85e882 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Denis for that proposal.=C2=A0
I believe we can already implement most of your idea with= =C2=A0https://github.com/ietf-wg-gnap/general/wiki/Modular-Interac= tion-Server. In particular, we can easily provide an interaction server= that is chosen by the Client (which might be operated by the Client itself= for instance, or by a party distinct from the AS). But for now, I'm st= ill going through the AS, who knows what the tokens are used for. Your use = case has the ability to change that.

So, I'm try= ing to figure out how 6.2 would work, regarding RS hiding and the need for = non opaque tokens.=C2=A0

You're saying : "= ;The choice of hiding or not hiding the true name of the RS is a choice mad= e by the Client. Such a choice may be handled through a local configuration= of the Client. If "privacy by default" is applied, hiding the tr= ue name of the RS should be the default choice.
The role of the AS is = to deliver the requested types of attributes into an access token without n= ecessarily knowing to which RS(s) the access token is intended."
<= br>
So, after the interaction with the RO, suppose we get a list = of tokens to mint (for instance in the format defined in XYZ), in this case= we expect to generate token1:=C2=A0
"token1": [
        {
            "actions": [
                "read"
            ],
            "locations": [
                "https://s=
erver.example.net/"
            ],
            "datatypes": [
                "metadata",
                "images"
            ]
        }
    ],

As per=C2=A0rfc7523, the AS would then mint a JWT ac= cess token, including "aud":"https://server.example.net".
Later the RS can ch= eck that the token has been generated with the right audience (amongst othe= r things).
Note that there's a proposal to provide more guida= nce on that topic=C2=A0https://github.com/ietf-wg-gnap/general/wiki/Di= rected-Access-Tokens. We can imagine it can soon become fairly complex.=

If I understand you well, you're suggesting a= n additional layer of indirection, in the form of alias to the locations ur= l?=C2=A0
Something in the form of:
1) The Client c= ontacts the RS for information
2) The RS responds to the Client (= including one-off aliases and their time to live)
3) The Client d= eals with consent (cf proposal related to the IS component), and the AS doe= sn't have to know what is asked
4) Based on what the RO conse= nted, the AS is asked to mint token1, token2, etc. with aliases
5= ) The Client uses the aliased tokens with the RS

=
I see the reason why you're suggesting that, but implementing that= at scale may be tricky. I don't see how a local configuration of the c= lient (as you suggest)=C2=A0is enough, you'll also need to share that i= nformation with the RS at some point. To work, the mapping between the Clie= nt and the RS would have to be private and probably even transient (if we c= an to avoid=C2=A0AS from scrawling RS endpoints for durable aliases, which = would defeat the purpose), which pose questions of cache invalidation and t= he synchronicity=C2=A0with the token itself.=C2=A0

Also you're saying (before step 5 occurs): "Once the Client has o= btained the requested access tokens, they are not immediately presented to = the RS: the Client should be able to verify that the content of each access= token is in accordance with each access token request."
I d= on't see the reason why the AS would present something else, especially= if it has no notion what=C2=A0is=C2=A0actually requested to whom (if the p= revious scheme is effective). If we suppose we're asking for read acces= s, maybe it could try a write access too, but for what use?=C2=A0
The suggested verification scheme on the Client side supposes that the Cli= ent is honest anyway. If so, the Client would only use the token for a read= request, so I don't understand which threat we're trying to avoid = (except from something theorical). If the Client is dishonest, it won't= care anyway.

Am I over complexifying what you hav= e in mind?

Fabien






<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 4, 2020 at 11:08 AM Denis = <denis.ietf@free.fr> wrote:=
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-g= nap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along= -%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000b6432a05ac85e882-- From nobody Mon Aug 10 07:21:28 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 EFB643A15E2 for ; Mon, 10 Aug 2020 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iRdzD1HqBj1d for ; Mon, 10 Aug 2020 07:21:25 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210723A15E1 for ; Mon, 10 Aug 2020 07:21:24 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07AELLeM021710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Aug 2020 10:21:21 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8F94205C-5B02-4E05-A2FE-C5494AB79C93" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 10 Aug 2020 10:21:20 -0400 In-Reply-To: Cc: Dick Hardt , Kathleen Moriarty , GNAP Mailing List To: Tom Jones References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [GNAP] [Txauth] Kathleen's review 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, 10 Aug 2020 14:21:27 -0000 --Apple-Mail=_8F94205C-5B02-4E05-A2FE-C5494AB79C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, could you expand why =E2=80=9CJOSE encoding=E2=80=9D is essential = to your use case?=20 =46rom what I=E2=80=99ve read of your proposals, most of your work seems = centered around claims in the access token itself that can be = interpreted by the RS components in the system. GNAP is going to remain = agnostic on the format of the access token, so JOSE can be used there as = always.=20 What=E2=80=99s being discussed below is using JOSE as the HTTP message = body format for the requests from the client to the AS (and potentially = return from the AS), not the token format or any kind of assertion = format. =E2=80=94 Justin > On Aug 6, 2020, at 4:15 PM, Tom Jones = wrote: >=20 > the only encoding that i care about is jose-encoding. Without it the = doc would just be advisory for my applications. > Peace ..tom >=20 >=20 > On Thu, Jul 30, 2020 at 1:36 PM Dick Hardt > wrote: > (adding in a subject) >=20 > Thanks for the clarification Kathleen! >=20 > I fully agree with you that we want developers to think of security = when reviewing the document. >=20 > Ironically, I wanted to ensure a Client developer knew they needed to = authenticate in all calls to the AS, and I had JOSE in every section in = the first drafts I sent to Justin for feedback, and he suggested I = factor it out into its own section, so that it would be easier to = specify other client authentication mechanisms such as MTLS and http = signing. I factored it into its own section, and then got feedback that = people preferred the JOSE client authentication to be a separate = document. >=20 > In the milestones for the WG[1], the core delegation protocol is a = milestone targeted for July 2021, and a key presentation mechanism is an = independent milestone targeted for Oct 2021. >=20 > In the charter we have anticipated having numerous key presentation = mechanisms, so separating the key presentation documents from the core = protocol seemed the right choice.=20 >=20 > Q: Are you suggesting we combine the documents? Or is there a = different recommendation to overcome what you saw as a security = deficiency in XAuth vs XYZ?=20 >=20 > As you know, there is much more to security than cryptography, and I = considered how to encourage best practices in the design. One of those = is the separation of concerns, which I wanted to encourage by using URIs = and HTTP methods so that GS decomposition was straight forward per = slides 11-13 of my presentation [2].=20 >=20 > In contrast to XYZ, XAuth requires the Grant URI and AZ URI to start = with the GS URI, so the Client has certainty on which GS a Grant or AZ = is for on receipt, and when working with the URIs later on. An opaque = token or handle stored in a database could be associated with any GS -- = so a self describing URI can assist in detecting an error in which GS it = belongs to. I think constraints like these improve security as more = errors can be detected, and attack vectors are reduced. >=20 > btw: A GS could have just one entry point if desired, the GS URI, and = the Grant URI and AZ URI could be represented by query parameters. >=20 > /Dick >=20 > [1] https://datatracker.ietf.org/group/gnap/about/ = >=20 > [2] = https://www.ietf.org/proceedings/108/slides/slides-108-gnap-xauth-dick-har= t-00 = >=20 >=20 > Would you confirm you were looking at -13 of XAuth? (The datatracker = tools are confused and depending on how you land on the page, the latest = version is not displayed) >=20 > In my first drafts that I shared offline with Justin, I had JOSE = client authentication throughout >=20 > Put JOSE Client authentication into a separate document in version = -08. >=20 > WG deliverables -- authentication is a separate document. >=20 >=20 >=20 >=20 > =46rom a security perspective, I focussed on the protocol aspects = rather than the security aspects. >=20 > interaction modes >=20 > URIs - based off of GS URI, methods and - decomposition >=20 > client knows which GS a Grant or AZ came from >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Jul 30, 2020 at 8:11 AM Kathleen Moriarty = > wrote: > Hey Dick, >=20 > Thanks for your questions and all of your hard work. I'll respond = inline as not to miss anything. >=20 > On Wed, Jul 29, 2020 at 1:07 PM Dick Hardt > wrote: > Hey Kathleen >=20 > A couple questions on your presentation: >=20 > 1) Which versions of the documents did you review? > Your last posted version to the datatracker. > I had started with the latest in the datatracker for Justin, but = switched when he announced the update. Although my skim on the = datatracker one had similar impressions in terms of structure, ease of = use, etc. > =20 >=20 > 2) Would you elaborate on your security comparisons of XAuth and XYZ? = I want to make sure I understand the work you put into your review. = While reviewing your slides, I was not following a number of your = statements. For example:=20 >=20 > In your first slide: >=20 > A) you stated that "XAuth Relies heavily on OAuth2.0, using Bearer = token and adding cryptographic (e.g.JOSE) functions after-the-fact". = Both XAuth and XYZ support bearer tokens for calling an RS. I'm not = clear how this feature is different in XAuth. >=20 > Sure, XAuth punts the use of security off in a section and is not more = integrated in the approach. That's how OAUth is now and it's something = that really should be fixed. Making it clear that security is an = afterthought makes it an afterthought for developer and implementers. = Industry is moving towards built-in intrinsic security. >=20 > You can do this just as easily, but XYZ mentioned security in the = flows/sequences as an inherent part of each. While it may not be = perfect yet, the theme was there. The references to exchange of a key = in section 2 and 3 with an editor note that this needs work are the = first places the idea of embedding begins. >=20 > The value generated in the access token doesn't explicitly use crypto, = but could. This is something to consider. > Section 4..4.2. - uses a HASH, but an HMAC or KMAC could be used. = This is in the feedback I will be posting. >=20 > Section 7 calls explicitly for use of a JWS and authorization values. >=20 > Section 8 provides more explicit guidance for add-on, but it's not in = a registry or another draft - part of this work. >=20 > Section 13 points to the need for more work, acknowledging multiple = ways to explore supporting security directly in the protocol.. >=20 >=20 >=20 >=20 >=20 > B) What parts of XYZ did you view as "Builds security into the = protocol as opposed to adding it in later (e.g. OAuth2.0 bearer token + = JWT)"?=20 > See above. It's a lot more clear than the single reference in XAuth. > =20 >=20 > C) "Interaction flows defined, focus more on security with = cryptographic requirements and examples included" -- there some = cryptography in the redirect flow, but not in the others. In my opinion, = the cryptography in the redirect flow does not add any value, and just = complicates the protocol.=20 >=20 > Perhaps you can point to sections in each draft? > See above. >=20 > Best regards, > Kathleen > =20 >=20 > Thanks! >=20 > /Dick >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_8F94205C-5B02-4E05-A2FE-C5494AB79C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tom, = could you expand why =E2=80=9CJOSE encoding=E2=80=9D is essential to = your use case? 

=46rom what I=E2=80=99ve read of your proposals, most of your = work seems centered around claims in the access token itself that can be = interpreted by the RS components in the system. GNAP is going to remain = agnostic on the format of the access token, so JOSE can be used there as = always. 

What=E2=80=99s being discussed below is using JOSE as the = HTTP message body format for the requests from the client to the AS (and = potentially return from the AS), not the token format or any kind of = assertion format.

 =E2=80=94 Justin

On Aug = 6, 2020, at 4:15 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

the only encoding that i care = about is jose-encoding. Without it the doc would just be advisory for my = applications.
Peace = ..tom


On Thu, Jul = 30, 2020 at 1:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
(adding= in a subject)

Thanks for the clarification Kathleen!

I fully agree with you = that we want developers to think of security when reviewing the = document.

Ironically, I wanted to ensure a Client developer knew they = needed to authenticate in all calls to the AS, and I had JOSE in every = section in the first drafts I sent to Justin for feedback, and he = suggested I factor it out into its own section, so that it would be = easier to specify other client authentication mechanisms such as = MTLS and http signing. I factored it into its own section, and then got = feedback that people preferred the JOSE client authentication to be a = separate document.

In the milestones for the WG[1], the core delegation protocol = is a milestone targeted for July 2021, and a key presentation mechanism = is an independent milestone targeted for Oct 2021.

In the charter we have = anticipated having numerous key presentation mechanisms, so separating = the key presentation documents from the core protocol seemed the = right choice. 

Q: Are you suggesting we combine the documents? Or is there a = different recommendation to overcome what you saw as a security = deficiency in XAuth vs XYZ? 

As you know, there is much more to = security than cryptography, and I considered how to encourage best = practices in the design. One of those is the separation of concerns, = which I wanted to encourage by using URIs and HTTP methods so that GS = decomposition was straight forward per slides 11-13 of my = presentation [2]. 

In contrast to XYZ, XAuth requires = the Grant URI and AZ URI to start with the GS URI, so = the Client has certainty on which GS a Grant or AZ is for on = receipt, and when working with the URIs later on. An opaque token or = handle stored in a database could be associated with any GS -- so a self = describing URI can assist in detecting an error in which GS it belongs = to. I think constraints like these improve security as more errors can = be detected, and attack vectors are reduced.

btw: A GS could have just one entry = point if desired, the GS URI, and the Grant URI and AZ URI could be = represented by query parameters.

/Dick

[1] https://datatracker.ietf.org/group/gnap/about/

[2] https://www.ietf.org/proceedings/108/slides/slides-108-gnap-xau= th-dick-hart-00


Would you confirm you = were looking at -13 of XAuth? (The datatracker tools are confused and = depending on how you land on the page, the latest version is not = displayed)

In = my first drafts that I shared offline with Justin, I had JOSE client = authentication throughout

Put JOSE Client authentication into a separate document in = version -08.

WG = deliverables -- authentication is a separate document.




=46rom a security perspective, I focussed on the = protocol aspects rather than the security aspects.

interaction = modes

URIs - = based off of GS URI, methods and - decomposition

client knows which GS a Grant or AZ = came from








On Thu, Jul 30, 2020 at 8:11 AM Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> wrote:
Hey Dick,

Thanks for your questions and all of your hard work.  = I'll respond inline as not to miss anything.

On Wed, Jul = 29, 2020 at 1:07 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Kathleen

A couple questions on your presentation:

1) Which versions of the = documents did you review?
Your last posted version to the datatracker.
I had started with the latest in the datatracker for Justin, = but switched when he announced the update.  Although my skim on the = datatracker one had similar impressions in terms of structure, ease of = use, etc.
 

2) Would = you elaborate on your security comparisons of XAuth and XYZ? I want to = make sure I understand the work you put into your review.  = While reviewing your slides, I was not following a number of your = statements. For example: 

In your first slide:

A) you stated that = "XAuth Relies heavily on OAuth2.0, using Bearer token and adding = cryptographic (e.g.JOSE) functions after-the-fact". Both XAuth and XYZ = support bearer tokens for calling an RS. I'm not clear how this feature = is different in XAuth.

Sure, XAuth punts the = use of security off in a section and is not more integrated in the = approach.  That's how OAUth is now and it's something that really = should be fixed.  Making it clear that security is an afterthought = makes it an afterthought for developer and implementers.  Industry = is moving towards built-in intrinsic security.

You can do this just as easily, but XYZ = mentioned security in the flows/sequences as an inherent part of = each.   While it may not be perfect yet, the theme was = there.  The references to exchange of a key in section 2 and 3 with = an editor note that this needs work are the first places the idea of = embedding begins.

The value generated in the access token doesn't = explicitly use crypto, but could.  This is something to = consider.
Section 4..4.2. - uses a HASH, but an = HMAC or KMAC could be used.  This is in the feedback I will be = posting.

Section= 7 calls explicitly for use of a JWS and authorization = values.

Section = 8 provides more explicit guidance for add-on, but it's not in a registry = or another draft - part of this work.

Section 13 points to the need for more = work, acknowledging multiple ways to explore supporting security = directly in the protocol..





B) What = parts of XYZ did you view as "Builds security into the protocol as opposed to adding it in later (e.g. OAuth2.0 bearer token + = JWT)"? 
See= above.  It's a lot more clear than the single reference in = XAuth.
 

C) = "Interaction flows defined, focus more on security with cryptographic requirements and examples included" -- there some cryptography in the redirect = flow, but not in the others. In my opinion, the cryptography in the = redirect flow does not add any value, and just complicates the = protocol. 

Perhaps you can point to sections in each = draft?
See = above.

Best = regards,
Kathleen
 

Thanks!

/Dick




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


--

Best = regards,
Kathleen
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_8F94205C-5B02-4E05-A2FE-C5494AB79C93-- From nobody Mon Aug 10 08:17:13 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 3616C3A16CD for ; Mon, 10 Aug 2020 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 w_BeeGj0l-ck for ; Mon, 10 Aug 2020 08:17:08 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 BECDA3A16C8 for ; Mon, 10 Aug 2020 08:17:08 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id t7so7558762otp.0 for ; Mon, 10 Aug 2020 08:17:08 -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=0KKTjHtI03d4WFMyao6F8rwbkvoW7i8couPY9cnz+6o=; b=V3PbAqy56QgSGSJaK+vRCkJcUVksbQxhzJ+L7tKGW0KNFckfTpmlGVpvmNXjgo5jI4 /5fKsF49T647T9JW9YQJCPRurBJ92pkLmWRlb5fQnxcb65cSD3l8hPPwSlJdWVLVk18j WweFB0uMfa07Zdqpr3HdpwDQzUWY1Yr5OHC2TUMjEw/OsjI3yKNjJ7gVReisD3WRmoLE f1mIimY81T4LtZzoQ6J6JTzyGOqx6iiZq4T5TMd4du2HDTw4aD5QFmoP0ycm1SQgAA/+ EANPet4jsURdSKl6DVHYufAToEQ0kIsw7goM9ue1ZmZgx14DXT6cEbEK1Tb81siOh1jE V5fQ== 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=0KKTjHtI03d4WFMyao6F8rwbkvoW7i8couPY9cnz+6o=; b=enZ/Lqg+FTy/dHDQdtMSuKuvfDGMc7EgBSqEK3jxVMbnbbtSw54+1yfFnNZWz7ufG1 OJ40ocXwhPbCByWrlg5mpnzj7qYBaeuC+zgG2A9VaqLafP5g8IN6VKnIaf06wGGS7Dg2 ZNgY9MK2MARAnxDXMRcHve8HICp0Q5Hy+WOof6GbhVU7U6cKsWOEuHoTitDVNrF18kPS 9NkXHku4B+hy3czuF2dqsX/Rr3/l3/yWJ0KaPCchA+zCLT0UbjAy6f/NogI3asnteUMx XADXUhs8U5xvHAldxaCl+onrACnOjT7djVGZDn7l3sSm+eXfSY8S/OV8dxeDqISZUeBe 8baw== X-Gm-Message-State: AOAM530jS6VWJtOOtF6+cFqetJ1Aj/AtWMfuECT3TpBKM0z88RRU9/rI lretV8Vt0UVnfIuwO5juWsbp3KDeJG6Ep6CCPZs= X-Google-Smtp-Source: ABdhPJx6sjWJaCNE3IOms0itkN7qzLmOd/bwz/w7OEfIh4TkymWEWCZC8pUf+KAxsKzo01KoOjQrCd8V9I9yfl5bUlo= X-Received: by 2002:a9d:3e49:: with SMTP id h9mr1137641otg.87.1597072627764; Mon, 10 Aug 2020 08:17:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Mon, 10 Aug 2020 08:16:56 -0700 Message-ID: To: Justin Richer Cc: Dick Hardt , Kathleen Moriarty , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a8940f05ac877299" Archived-At: Subject: Re: [GNAP] [Txauth] Kathleen's review 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, 10 Aug 2020 15:17:11 -0000 --000000000000a8940f05ac877299 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your interpretation is correct. My statement is, and remains, that we require jose encoding to build a token that can carry the little token "niblets" within the AZ token that are jose encoded. Dick's broad statement about encoding is problematic for us. I also jose encode the entire token, but I admit that is merely a convenience for my own implementations. BTW - other encodings, like cbor, are of interest, but somehow encoding must be addressed and included in the spec so that any comformate token can be appropriately handled. I see that the W3C CCG is struggling with this now. I hope they are able to propose a meta-encoding that can be used here. Peace ..tom On Mon, Aug 10, 2020 at 7:21 AM Justin Richer wrote: > Tom, could you expand why =E2=80=9CJOSE encoding=E2=80=9D is essential to= your use case? > > From what I=E2=80=99ve read of your proposals, most of your work seems ce= ntered > around claims in the access token itself that can be interpreted by the R= S > components in the system. GNAP is going to remain agnostic on the format = of > the access token, so JOSE can be used there as always. > > What=E2=80=99s being discussed below is using JOSE as the HTTP message bo= dy format > for the requests from the client to the AS (and potentially return from t= he > AS), not the token format or any kind of assertion format. > > =E2=80=94 Justin > > On Aug 6, 2020, at 4:15 PM, Tom Jones > wrote: > > the only encoding that i care about is jose-encoding. Without it the doc > would just be advisory for my applications. > Peace ..tom > > > On Thu, Jul 30, 2020 at 1:36 PM Dick Hardt wrote: > >> (adding in a subject) >> >> Thanks for the clarification Kathleen! >> >> I fully agree with you that we want developers to think of security when >> reviewing the document. >> >> Ironically, I wanted to ensure a Client developer knew they needed to >> authenticate in all calls to the AS, and I had JOSE in every section in = the >> first drafts I sent to Justin for feedback, and he suggested I factor it >> out into its own section, so that it would be easier to specify >> other client authentication mechanisms such as MTLS and http signing. I >> factored it into its own section, and then got feedback that people >> preferred the JOSE client authentication to be a separate document. >> >> In the milestones for the WG[1], the core delegation protocol is a >> milestone targeted for July 2021, and a key presentation mechanism is an >> independent milestone targeted for Oct 2021. >> >> In the charter we have anticipated having numerous key presentation >> mechanisms, so separating the key presentation documents from the core >> protocol seemed the right choice. >> >> Q: Are you suggesting we combine the documents? Or is there a different >> recommendation to overcome what you saw as a security deficiency in XAut= h >> vs XYZ? >> >> As you know, there is much more to security than cryptography, and I >> considered how to encourage best practices in the design. One of those i= s >> the separation of concerns, which I wanted to encourage by using URIs an= d >> HTTP methods so that GS decomposition was straight forward per slides 11= -13 >> of my presentation [2]. >> >> In contrast to XYZ, XAuth requires the Grant URI and AZ URI to start wit= h >> the GS URI, so the Client has certainty on which GS a Grant or AZ is for= on >> receipt, and when working with the URIs later on. An opaque token or han= dle >> stored in a database could be associated with any GS -- so a self >> describing URI can assist in detecting an error in which GS it belongs t= o. >> I think constraints like these improve security as more errors can be >> detected, and attack vectors are reduced. >> >> btw: A GS could have just one entry point if desired, the GS URI, and th= e >> Grant URI and AZ URI could be represented by query parameters. >> >> /Dick >> >> [1] https://datatracker.ietf.org/group/gnap/about/ >> >> [2] >> https://www.ietf.org/proceedings/108/slides/slides-108-gnap-xauth-dick-h= art-00 >> >> >> Would you confirm you were looking at -13 of XAuth? (The datatracker >> tools are confused and depending on how you land on the page, the latest >> version is not displayed) >> >> In my first drafts that I shared offline with Justin, I had JOSE client >> authentication throughout >> >> Put JOSE Client authentication into a separate document in version -08. >> >> WG deliverables -- authentication is a separate document. >> >> >> >> >> From a security perspective, I focussed on the protocol aspects rather >> than the security aspects. >> >> interaction modes >> >> URIs - based off of GS URI, methods and - decomposition >> >> client knows which GS a Grant or AZ came from >> >> >> >> >> >> >> >> >> On Thu, Jul 30, 2020 at 8:11 AM Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hey Dick, >>> >>> Thanks for your questions and all of your hard work. I'll respond >>> inline as not to miss anything. >>> >>> On Wed, Jul 29, 2020 at 1:07 PM Dick Hardt wrote= : >>> >>>> Hey Kathleen >>>> >>>> A couple questions on your presentation: >>>> >>>> 1) Which versions of the documents did you review? >>>> >>> Your last posted version to the datatracker. >>> I had started with the latest in the datatracker for Justin, but >>> switched when he announced the update. Although my skim on the datatra= cker >>> one had similar impressions in terms of structure, ease of use, etc. >>> >>> >>>> >>>> 2) Would you elaborate on your security comparisons of XAuth and XYZ? = I >>>> want to make sure I understand the work you put into your review. Whi= le >>>> reviewing your slides, I was not following a number of your statements= . For >>>> example: >>>> >>>> In your first slide: >>>> >>>> A) you stated that "XAuth Relies heavily on OAuth2.0, using Bearer >>>> token and adding cryptographic (e.g.JOSE) functions after-the-fact". B= oth >>>> XAuth and XYZ support bearer tokens for calling an RS. I'm not clear h= ow >>>> this feature is different in XAuth. >>>> >>> >>> Sure, XAuth punts the use of security off in a section and is not more >>> integrated in the approach. That's how OAUth is now and it's something >>> that really should be fixed. Making it clear that security is an >>> afterthought makes it an afterthought for developer and implementers. >>> Industry is moving towards built-in intrinsic security. >>> >>> You can do this just as easily, but XYZ mentioned security in the >>> flows/sequences as an inherent part of each. While it may not be perf= ect >>> yet, the theme was there. The references to exchange of a key in secti= on 2 >>> and 3 with an editor note that this needs work are the first places the >>> idea of embedding begins. >>> >>> The value generated in the access token doesn't explicitly use crypto, >>> but could. This is something to consider. >>> Section 4..4.2. - uses a HASH, but an HMAC or KMAC could be used. This >>> is in the feedback I will be posting. >>> >>> Section 7 calls explicitly for use of a JWS and authorization values. >>> >>> Section 8 provides more explicit guidance for add-on, but it's not in a >>> registry or another draft - part of this work. >>> >>> Section 13 points to the need for more work, acknowledging multiple way= s >>> to explore supporting security directly in the protocol.. >>> >>> >>> >>> >>> >>>> B) What parts of XYZ did you view as "Builds security into the protoco= l >>>> as opposed to adding it in later (e.g. OAuth2.0 bearer token + JWT)"? >>>> >>> See above. It's a lot more clear than the single reference in XAuth. >>> >>> >>>> >>>> C) "Interaction flows defined, focus more on security with >>>> cryptographic requirements and examples included" -- there some >>>> cryptography in the redirect flow, but not in the others. In my opinio= n, >>>> the cryptography in the redirect flow does not add any value, and just >>>> complicates the protocol. >>>> >>>> Perhaps you can point to sections in each draft? >>>> >>> See above. >>> >>> Best regards, >>> Kathleen >>> >>> >>>> >>>> Thanks! >>>> >>>> /Dick >>>> >>>> >>>> >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000a8940f05ac877299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your interpretation is=C2=A0correct. My statement is, and = remains, that we require jose encoding to build a token that can carry the = little token "niblets" within the AZ token that are jose encoded.= Dick's broad statement about encoding is problematic for us. I also jo= se encode the entire token, but I admit that is merely=C2=A0a convenience f= or my own implementations. BTW - other encodings, like cbor, are of interes= t, but somehow encoding must be addressed and included in the spec so that = any comformate token can be appropriately=C2=A0handled. I see that the W3C = CCG is struggling with this now. I hope they are able to propose a meta-enc= oding that can be used here.
Peace ..tom


On Mon, Aug 10, 2020 at 7:21 AM J= ustin Richer <jricher@mit.edu>= wrote:
Tom, could you expand why =E2=80=9CJOSE e= ncoding=E2=80=9D is essential to your use case?=C2=A0

Fr= om what I=E2=80=99ve read of your proposals, most of your work seems center= ed around claims in the access token itself that can be interpreted by the = RS components in the system. GNAP is going to remain agnostic on the format= of the access token, so JOSE can be used there as always.=C2=A0
=
What=E2=80=99s being discussed below is using JOSE as the HT= TP message body format for the requests from the client to the AS (and pote= ntially return from the AS), not the token format or any kind of assertion = format.

=C2=A0=E2=80=94 Justin

On Aug 6, 2020, at 4:15 PM, Tom Jones <thomasclinganjon= es@gmail.com> wrote:

the only encodin= g that i care about is jose-encoding. Without it the doc would just be advi= sory for my applications.
Peace ..tom


On Thu, Jul 30, 2020= at 1:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
(adding in a su= bject)

Thanks for the clar= ification Kathleen!

I fully agree with you that we want = developers to think of security when reviewing the document.

=
Ironically, I wanted to ensure a Client developer knew they need= ed to authenticate in all calls to the AS, and I had JOSE in every section = in the first drafts I sent to Justin for feedback, and he suggested I facto= r it out into its own section,=C2=A0so that it would be easier to specify o= ther=C2=A0client authentication mechanisms such as MTLS and http signing. I= factored it into its own section, and then got feedback that people prefer= red the JOSE client authentication to be a separate document.
In the milestones for the WG[1], the core delegation protocol i= s a milestone targeted for July 2021, and a key presentation mechanism is a= n independent milestone targeted for Oct 2021.

In = the charter we have anticipated having numerous key presentation mechanisms= , so separating the key presentation=C2=A0documents from the core protocol = seemed the right choice.=C2=A0

Q: Are you suggesti= ng we combine the documents? Or is there a different recommendation to over= come what you saw as a security deficiency in XAuth vs XYZ?=C2=A0

As you know, there is much more to security than cryptograp= hy,=C2=A0and I considered how to encourage best practices in the design. On= e of those is the separation of concerns, which I wanted to encourage by us= ing URIs and HTTP methods so that GS decomposition was straight forward per= slides 11-13 of my presentation=C2=A0[2].=C2=A0

I= n contrast to XYZ, XAuth requires the=C2=A0Grant URI and AZ URI to start wi= th the=C2=A0GS URI, so the=C2=A0Client has certainty on which GS a Grant or= AZ is for on receipt, and when working with the URIs later on. An opaque t= oken or handle stored in a database could be associated with any GS -- so a= self describing URI can assist in detecting an error in which GS it belong= s to. I think constraints like these improve security as more errors can be= detected, and attack vectors are reduced.

btw: A = GS could have just one entry point if desired, the GS URI, and the Grant UR= I and AZ URI could be represented by query parameters.

=
/Dick




Would you c= onfirm you were looking at -13 of XAuth? (The datatracker tools are confuse= d and depending on how you land on the page, the latest version is not disp= layed)

In my first drafts that I shared offline wi= th Justin, I had JOSE client authentication throughout

=
Put JOSE Client authentication into a separate document in version -08= .

WG deliverables -- authentication is a separate = document.




=
From a security=C2=A0perspective, I focussed on the protocol aspects r= ather than the security aspects.

interaction modes=

URIs - based off of GS URI, methods and - decompo= sition

client knows which GS a Grant or AZ came fr= om







=
On Thu, Jul 30, 2020 at 8:11 AM Kathl= een Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hey Dick,=

Thanks for your questions and all of your hard wo= rk.=C2=A0 I'll respond inline as not to miss anything.

On Wed, Jul 29, 2= 020 at 1:07 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Kathleen

A couple question= s on your presentation:

1) Which versions of the d= ocuments did you review?
You= r last posted version to the datatracker.
I had started with the = latest in the datatracker for Justin, but switched when he announced the up= date.=C2=A0 Although my skim on the datatracker one had similar impressions= in terms of structure, ease of use, etc.
=C2=A0

2) Would you elaborate = on your security comparisons of XAuth and XYZ? I want to make sure I unders= tand the=C2=A0work you put into your review.=C2=A0 While reviewing your sli= des, I was not following a number of your statements. For example:=C2=A0

In your first slide:

A) you= stated that "XAuth Relies heavily on OAuth2.0, using Bearer token and= adding cryptographic (e.g.JOSE) functions after-the-fact". Both XAuth= and XYZ support bearer tokens for calling an RS. I'm not clear how thi= s feature is different in XAuth.
=

Sure, XAuth punts the use of security off in a section = and is not more integrated in the approach.=C2=A0 That's how OAUth is n= ow and it's something that really should be fixed.=C2=A0 Making it clea= r that security is an afterthought makes it an afterthought for developer a= nd implementers.=C2=A0 Industry is moving towards built-in intrinsic securi= ty.

You can do this just as easily, but XYZ mentio= ned security in the flows/sequences as an inherent=C2=A0part of each.=C2=A0= =C2=A0While it may not be perfect yet, the theme was there.=C2=A0 The refe= rences to exchange of a key in section 2 and 3 with an editor note that thi= s needs work are the first places the idea of embedding begins.
<= br>
The value generated in the=C2=A0access token doesn't expl= icitly use crypto, but could.=C2=A0 This is something to consider.
Section 4..4.2. - uses a HASH, but an HMAC or KMAC could be used.=C2=A0 T= his is in the feedback I will be posting.

Section = 7 calls explicitly=C2=A0for use of a JWS and authorization values.

Section 8 provides more explicit guidance for add-on, but = it's not in a registry or another draft - part of this work.
=
Section 13 points to the need for more work, acknowledging= =C2=A0multiple ways to explore supporting security directly in the protocol= ..





B) What parts of XY= Z did you view as "Builds security into the protocol as opposed to adding it in later (e.g. OAuth2.0 bearer token + JWT)"?=C2=A0
=
See above.=C2=A0 It's a lot more clear than the single reference i= n XAuth.
=C2=A0
<= div>
C) "Interaction flows defined, focus more on security with cryptographic requirements and examples included" -- there some cryptography=C2=A0in the redirect= flow, but not in the others. In my=C2=A0opinion, the cryptography in the r= edirect flow does not add any value, and just complicates the protocol.=C2= =A0

Perhaps you can point to sections in each draf= t?
See above.

=
Best regards,
Kathleen
=C2=A0
=

Thanks!
/Dick



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


--

Best regards,
Kathleen
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--000000000000a8940f05ac877299-- From nobody Mon Aug 10 19:17:14 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 878CC3A0EDE for ; Mon, 10 Aug 2020 19:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Kyq835wAny-B for ; Mon, 10 Aug 2020 19:17:10 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 955A63A0EC6 for ; Mon, 10 Aug 2020 19:17:09 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id g8so1215384wmk.3 for ; Mon, 10 Aug 2020 19:17:09 -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=/YVwbTCbRzb02xSXOr4Mf4E2gZB7A5QsHu+jLFyxuTs=; b=XjWvkYAAat3C3L1ZTcppdimLrbqINTwhnRzoUgyfK5JEMSQ+BAumZI2LdB3ItXuxYz IDmDxQYYm9RuEeJylo6CJ7CnnyQq5YHoaqHRnJUyeHrq5DwzfTAM09jC7sOjdqWuGpRg 0K4KNO1RTyssZYmpRFV2hjC4/hMUPngDgRjnw= 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=/YVwbTCbRzb02xSXOr4Mf4E2gZB7A5QsHu+jLFyxuTs=; b=kt0JLlk+dYkn37kA52fObRel8Vhc54Ha90QrZF2H6JSg9IJvDbgwbqNE4kk4K4rUtU 22S4payvRGvOLlxVEwuhhWLL5E7Wznpjy+y7Q8iXDSwirkrUqXPz9qcEWKqjErBm7iNS q6xVsyYjuHVzq/gTT25J3Tr3R0T+O+gfW2ahzPC58dbZMcy5VBXhuABJOIL4hDUoBWLX 2dwRvoeGGNC4IItUb+/lfKhK9O+RPqBJ+HjVI3heyQLQpELAWQFKYZOj8kv77ioBLmbN vW3KmkJE77IKYBD6M4Sz5nvwdGiDSmLeRfOt37yU3lqOvdr00okEI66PJVjaUXPaZM6Q XIHw== X-Gm-Message-State: AOAM5331yRnpS7Qv1/VfyjJeBmHvS5m+ICMgS/Tk8TTqKJ2vX01aNrrb mpcQsY2ZNVvFPCeKeNitsqSHFyvtBtjxHCRxTmFASQ== X-Google-Smtp-Source: ABdhPJwQbpIMSWjAuQ9P8XWQktAv7ZuQPBIF2klWs144m5f6GOySa1EA798jfqJWO39VL40OYMVtVgecPvrycATMek0= X-Received: by 2002:a1c:b145:: with SMTP id a66mr1860628wmf.133.1597112227592; Mon, 10 Aug 2020 19:17:07 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> In-Reply-To: From: Francis Pouatcha Date: Mon, 10 Aug 2020 22:16:56 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , Fabien Imbault , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fe229605ac90aa21" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 02:17:12 -0000 --000000000000fe229605ac90aa21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Denis, Justin, Dick, Fabien, In this post ( https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between "Requestor" (a.k.a. User), AS and RS to obtain the protected resource. We are turning around the same topic. As soon as we go beyond the original oAuth protocol, the word 'Client' becomes confusing. In the same response, I suggest we talk about "roles" and not "entities". Best regards. /Francis On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: > I still think that client was the right name in OAuth 2, as the client > wanted to do a client-server interaction, so the client used OAuth 2 to g= et > an access token to interact with the "server". > > I do agree that it is not the best term in GNAP. Primarily because GNAP i= s > a combination of the client from OAuth 2, and the relying party from OIDC= . > > /Dick > =E1=90=A7 > > On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: > >> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >> >> >> The term client in OAuth came from the computer science definition of >> client-server interaction. >> >> >> This, I would argue, is exactly why it=E2=80=99s a bad label for somethi= ng that=E2=80=99s >> distinctly more specific in this context, and I would love to see GNAP >> adopt a more specific label for the role that we traditionally called >> =E2=80=9Cclient=E2=80=9D in OAuth. >> >> =E2=80=94 Justin >> >> >> The client is getting an access token so it can call a server, >> specifically, a resource server (to differentiate it from the authorizat= ion >> server). >> >> The confusion in my experience usually stems from people working with >> software that is acting in multiple roles. IE, the software that is acti= ng >> as a client in once context, is also acting as an RS in other contexts, = or >> even acting as an AS. The other confusion is that people view clients as >> being the software the user is using -- although it may not be acting as= a >> client in the oauth context. >> >> >> >> =E1=90=A7 >> >> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >> wrote: >> >>> Hi, >>> >>> To me, client has always been a strange word in the context of OAuth, a= s >>> it has a meaning well defined both in everyday life (this client is a g= ood >>> customer) and in computer science (client-server interaction). Thus I >>> always have to make the mental translation to the OAuth world before an= y >>> discussion... And any teaching experience shows that it does make the >>> concepts hard to grasp for a majority of (clever) people. >>> >>> As for the RO, previous discussions suggested Resource >>> Controller (RC) also, which may be a bit more specific than manager. >>> >>> Fabien >>> >>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>> >>>> Justin and Dick, >>>> >>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>> the creation of OAuth)"] >>>> >>>> So let us attempt to define new terms: >>>> >>>> *initiating application (IA)*: application by means of which a user >>>> initiates interactions with RS(s) and AS(s) >>>> >>>> In the same way, we should get rid of the term Resource Owner (RO), >>>> which is currently defined as: >>>> >>>> Resource Owner (RO): entity capable of granting access to a protected >>>> resource >>>> >>>> I propose to replace it with Resource Manager (RM): >>>> >>>> *Resource Manager (RM)* : application or user that manages an access >>>> decision function of a Resource Server >>>> >>>> Denis >>>> >>>> I agree with Justin. Redefining well used terms will lead to >>>> significant confusion. If we have a different role than what we have h= ad >>>> in the past, then that role should have a name not being used already = in >>>> OAuth or OIDC. >>>> >>>> Given what we have learned, and my own experience explaining what a >>>> Client is, and is not, improving the definition for Client could prove >>>> useful. I am not suggesting the term be redefined, but clarified. >>>> >>>> For example, clarifying that a Client is a role an entity plays in the >>>> protocol, and that the same entity may play other roles at other times= , or >>>> some other language to help differentiate between "role" and "entity". >>>> >>>> /Dick >>>> =E1=90=A7 >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>>> >>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a be= tter fit, but I=E2=80=99m >>>>> not really in favor of taking an existing term and applying a complet= ely >>>>> new definition to it. In other words, I would sooner stop using =E2= =80=9Cclient=E2=80=9D >>>>> and come up with a new, more specific and accurate term for the role = than >>>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely di= fferent. We did this >>>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserv= er=E2=80=9D on its own but instead >>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>> >>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>> ignore the fact that GNAP is going to be coming up in a world that is >>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t h= ave a blank >>>>> slate to work with, but neither are we bound to use the same terms an= d >>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>> >>>>> I think that is fundamentally part of the question: >>>>> >>>>>> We are clear that we are producing a protocol that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusin= g >>>>>> terms >>>>>> from OAuth 2.0 but with different definitions may lead to unnecessar= y >>>>>> confusion >>>>> >>>>> >>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>> should not change the meanings of any definition. If we are saying th= is >>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick th= e best >>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I ha= ve a >>>>> lot of first hand experience of industries "ruining words", and attem= pting >>>>> to side-step the problem rather than redefining the word just confuse= s >>>>> everyone as everyone forgets the original meaning as new documents co= me >>>>> out, but the confusion with the use of a non-obvious word continues. >>>>> >>>>> Food for thought. >>>>> - Warren >>>>> >>>>> Warren Parad >>>>> Founder, CTO >>>>> Secure your user data and complete your authorization architecture. >>>>> Implement Authress . >>>>> >>>>> >>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>>> >>>>>> Hi Denis, >>>>>> >>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>> > Hi Justin, >>>>>> > >>>>>> > Since you replied in parallel, I will make a response similar to >>>>>> the one >>>>>> > I sent to Dick. >>>>>> > >>>>>> > > Hi Denis, >>>>>> > > >>>>>> > > I think there=E2=80=99s still a problem with the terminology in = use here. >>>>>> What >>>>>> > > you describe as RS2, which might in fact be an RS unto itself, i= s >>>>>> a >>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clie= nt of RS1/. What >>>>>> you >>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth wor= ld, but it is not >>>>>> at >>>>>> > > all the same as an OAuth client. I appreciate your mapping of th= e >>>>>> > > entities below, but it makes it difficult to hold a discussion i= f >>>>>> we >>>>>> > > aren=E2=80=99t using the same terms. >>>>>> > > >>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can >>>>>> define >>>>>> > > our own terms. The bad news is that this is really hard to do. >>>>>> > > >>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with ne= w >>>>>> definitions, >>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we de= fine >>>>>> things. >>>>>> > >>>>>> > In the ISO context, each document must define its own terminology. >>>>>> The >>>>>> > boiler plate for RFCs does not mandate a terminology or definition= s >>>>>> section >>>>>> > but does not prevent it either. The vocabulary is limited and as >>>>>> long as >>>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>>> already >>>>>> > used in another RFC. This is also the ISO approach. >>>>>> >>>>>> Just because we can do something does not necessarily mean that it i= s >>>>>> a >>>>>> good idea to do so. We are clear that we are producing a protocol >>>>>> that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusin= g >>>>>> terms >>>>>> from OAuth 2.0 but with different definitions may lead to unnecessar= y >>>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>>> Dick to >>>>>> use the term "GS" in XAuth, picking a name that was not already used >>>>>> in >>>>>> OAuth 2.0. >>>>>> >>>>>> -Ben >>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000fe229605ac90aa21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Denis, Justin, Dick, Fabien,

In t= his post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_= KimjOBJqdmQY-JOGNw/) i suggested we use the word "Orchestrator&quo= t; to designate the piece of software that orchestrate interaction between = "Requestor" (a.k.a. User), AS and RS to obtain the protected reso= urce.=C2=A0

We are turning around the same topic. = As soon as we go beyond=C2=A0the original oAuth protocol, the word 'Cli= ent' becomes confusing.

In the same response, = I suggest=C2=A0we talk about "roles" and not "entities"= .

Best regards.
/Francis

=
On Thu, Au= g 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I still think that client was the rig= ht name in OAuth 2, as the client wanted to do a client-server interaction,= so the client used OAuth 2 to get an access token to interact with the &qu= ot;server".

I do agree that it is not the best = term in GNAP. Primarily because GNAP is a combination of the client from OA= uth 2, and the relying party from OIDC.=C2=A0

/Dic= k
=E1=90=A7

On Thu, Aug 6, 2020 at 12:50 PM= Justin Richer <jri= cher@mit.edu> wrote:
On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com> wr= ote:

The term c= lient in OAuth came from the computer science definition of client-server i= nteraction.

This, I would argue= , is exactly why it=E2=80=99s a bad label for something that=E2=80=99s dist= inctly more specific in this context, and I would love to see GNAP adopt a = more specific label for the role that we traditionally called =E2=80=9Cclie= nt=E2=80=9D in OAuth.

=C2=A0=E2=80=94 Justin
=

The= client is getting an access token so it can call a server, specifically, a= resource server (to differentiate it from the authorization server).
=

The confusion in my experience usually stems from peopl= e working=C2=A0with software=C2=A0that is acting in multiple=C2=A0roles. IE= , the software=C2=A0that is acting as a client in once context, is also act= ing as an RS in other contexts, or even acting as an AS. The other confusio= n is that people view clients as being the software the user is using -- al= though it may not be acting as a client in the oauth context.


3D""=E1=90=A7<= /div>
O= n Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:=
Hi,=C2=A0

To me, client has always been a strange word= in the context of OAuth, as it has a meaning well defined both in everyday= life (this client is a good customer) and in computer science (client-serv= er interaction). Thus I always have to make the mental translation to the O= Auth world before any discussion... And any teaching experience shows that = it does make the concepts hard to grasp for a majority of (clever) people.<= /div>

As for the RO, previous discussions suggested Reso= urce Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific than = manager.=C2=A0

Fabien=C2=A0

On Thu, Aug 6, 20= 20 at 1:00 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth
--
Txauth mailing list
= Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

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


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

--
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/
--000000000000fe229605ac90aa21-- From nobody Mon Aug 10 20:04:30 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 BF8483A07A5 for ; Mon, 10 Aug 2020 20:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 j4Wnj6n80h_f for ; Mon, 10 Aug 2020 20:04:26 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 17FB33A0797 for ; Mon, 10 Aug 2020 20:04:25 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 3so1419817wmi.1 for ; Mon, 10 Aug 2020 20:04:25 -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=ZoKVZYhrjI0bXVk6h7CTk+rtBr+m5klTaDSUNhhxcQc=; b=GDKIUIvIZqsjwryYSiQHuuuw+XERRm3Tkk53Y+L9n77aq9VQDN4WBZZAT51FfQcJP6 kBfUSFtdl/TNNUonYSJQfA5sGK2GahZ3RKgxEp5vCBiAL0naLrTLFHGT5lD0jALeYd0n ST3AiR0jYzhezKdQNxIAfab38fK5MVx9ed4cs= 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=ZoKVZYhrjI0bXVk6h7CTk+rtBr+m5klTaDSUNhhxcQc=; b=dFXP+gK/XFc1ajd5/vdsIui0XTsy+PxIOoEhLHG8ThRBaJgBQa71/DLAnFPiUlKHPE 1LmTJrFJeSVmFopcMVka671fzPyCOkCe4xbSNqTgW+vaUgVs0eQ/y2yAl7YjNI7WsicD 0WUjKhu7yZmUsQ9e0MUko2Gc7OyVZT7K5pedwZfXSxVz9COIBzChBgLTZXvkFZScdCGN h0b1/7lRgbpwqOPxP2vO/cVPgdxmhMJ4knA0Nxn6Xxdx5B02lD/bI6lzgW0NbbNXf6di clnlqJoKKZoQZJqyRh7VvcUafR4wvVWm/ODqj5iRbXjcxDYngyNZBWjnuZLWadcERuZy MORQ== X-Gm-Message-State: AOAM5324+EL0DoMKmTXHVTQWTAchwYD6RP03yClTZ1gTCxNh5emXGCHS N4RQrSX+cyo9SdzyxIjypYvmN9cTO9GEOlcjlwhuuw== X-Google-Smtp-Source: ABdhPJwzHiPX/RzZAUrwYXbe32ah5ktg1V2IaiufJb+vnB/Ml1HFTVWjlSa99uE9iXJUiKBecFHClvYcMPp4PfHcR+c= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr1846231wml.38.1597115064195; Mon, 10 Aug 2020 20:04:24 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Francis Pouatcha Date: Mon, 10 Aug 2020 23:04:13 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001134a605ac915483" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 11 Aug 2020 03:04:29 -0000 --0000000000001134a605ac915483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol. In this diagram from the original thread ( https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words: +-----------+ +--------------+ +----+ +----+ +---------------------= + | Requestor | | Orchestrator | | | | GS | | Resource Controller = | | was | | was | | RS | | or | | was = | | User | | Client | | | | AS | | Resource Owner = | +-----------+ +--------------+ +----+ +----+ +---------------------= + |(1) ServiceRequest | | | | |---------------------->| | | | | |(2) ServiceIntent:AuthZChallenge | | |<---------->| | | | | | | | | |(3) AuthZRequest(AuthZChallenge) | | |------------------->| | | | | |(4) ConsentRequest:Grant | | | |<-------------->| | |(5) GrantAccess(AuthZ) | | |<-------------------| | | | | | | | |(6) ServiceRequest(AuthZ):ServiceResponse | |<---------->| | | |(7) ServiceResponse | | | | |<----------------------| | | | + + + + + The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing. It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition. We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2. Best regards. /Francis On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt wrote: > I agree with Justin. Redefining well used terms will lead to significant > confusion. If we have a different role than what we have had in the past, > then that role should have a name not being used already in OAuth or OIDC= . > > Given what we have learned, and my own experience explaining what a Clien= t > is, and is not, improving the definition for Client could prove useful. I > am not suggesting the term be redefined, but clarified. > > For example, clarifying that a Client is a role an entity plays in the > protocol, and that the same entity may play other roles at other times, o= r > some other language to help differentiate between "role" and "entity". > > /Dick > =E1=90=A7 > > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: > >> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bette= r fit, but I=E2=80=99m >> not really in favor of taking an existing term and applying a completely >> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >> and come up with a new, more specific and accurate term for the role tha= n >> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diffe= rent. We did this >> in going from OAuth 1 to OAuth 2 already, moving from the >> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >> >> GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is >> ignore the fact that GNAP is going to be coming up in a world that is >> already permeated by OAuth 2 and its terminology. We don=E2=80=99t have= a blank >> slate to work with, but neither are we bound to use the same terms and >> constructs as before. It=E2=80=99s going to be a delicate balance! >> >> =E2=80=94 Justin >> >> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >> >> I think that is fundamentally part of the question: >> >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion >> >> >> If we say that this document assumes OAuth2.0 terminology, then we shoul= d >> not change the meanings of any definition. If we are saying this superse= des >> or replaces what OAuth 2.0 creates, then we should pick the best word fo= r >> the job and ignore conflicting meanings from OAuth 2.0. I have a lot of >> first hand experience of industries "ruining words", and attempting to >> side-step the problem rather than redefining the word just confuses >> everyone as everyone forgets the original meaning as new documents come >> out, but the confusion with the use of a non-obvious word continues. >> >> Food for thought. >> - Warren >> >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >> >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response similar to the >>> one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in use= here. >>> What >>> > > you describe as RS2, which might in fact be an RS unto itself, is a >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world,= but it is not at >>> > > all the same as an OAuth client. I appreciate your mapping of the >>> > > entities below, but it makes it difficult to hold a discussion if w= e >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can >>> define >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>> definitions, >>> > > but we=E2=80=99ve got a chance to be more precise with how we defin= e things. >>> > >>> > In the ISO context, each document must define its own terminology. Th= e >>> > boiler plate for RFCs does not mandate a terminology or definitions >>> section >>> > but does not prevent it either. The vocabulary is limited and as long >>> as >>> > we clearly define what our terms are meaning, we can re-use a term >>> already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily mean that it is a >>> good idea to do so. We are clear that we are producing a protocol that >>> is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted Dic= k >>> to >>> use the term "GS" in XAuth, picking a name that was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000001134a605ac915483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this context, I suggest we pic= k some words to work with, and sharpen them as we move on, discover and map= new use cases to the protocol.

In this diagram from the original t= hread (https://mailarchive.ietf.org/arc= h/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+--= --+ =C2=A0+----+ =C2=A0+---------------------+
| Requestor |= =C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0 =C2=A0 | =C2=A0| GS | = =C2=A0| Resource Controller |
|= =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0RS=C2=A0|=C2=A0 |=C2=A0or |=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
|=C2=A0 User=C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0|=C2=A0= |=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 Resource Owner=C2= =A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------= + =C2=A0+----+ =C2=A0+----+ =C2=A0+---------------------+
=C2= =A0 |(1) ServiceRequest=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2= =A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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) ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->= ;|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= -------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):= ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<--------= --------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 = =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +

<= font face=3D"monospace">The purpose of the GNAP protocol is to help negotia= te access to a protected resource. It starts with a requestor delegating activity to an orchestrator. The= se are all roles, no entities. Let focus on mapping the use cases to the pr= otocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussion= s as it is impossible to give the word "Client" a clear definitio= n.

=
We can mention=C2=A0in the final= document, that the "Orchestrator" (or whatever word we finally u= se) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis




On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I agree wit= h Justin. Redefining well used terms will lead to significant confusion. If= we have a different role than what we have had in=C2=A0the past, then that= role should have a name not being used already in OAuth or OIDC.

<= /div>
Given what we have learned, and my own experience explaining what= a Client is, and is not, improving the definition for Client could prove u= seful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an ent= ity plays in the protocol, and that the same entity may play other roles at= other times, or some other language to help differentiate between "ro= le" and "entity".

/Dick
=
3D""=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer= <jricher@mit..edu<= /a>> wrote:
<= div>I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m not really in favor of taking an existing term and = applying a completely new definition to it. In other words, I would sooner = stop using =E2=80=9Cclient=E2=80=9D and come up with a new, more specific a= nd accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as me= aning something completely different. We did this in going from OAuth 1 to = OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2= =80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the ter= m =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2=80= =9D on its own but instead always qualifies it with =E2=80=9CAuthorization = Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

G= NAP can do something similar, in my opinion. But what we can=E2=80=99t do i= s ignore the fact that GNAP is going to be coming up in a world that is alr= eady permeated =C2=A0by OAuth 2 and its terminology. We don=E2=80=99t have = a blank slate to work with, but neither are we bound to use the same terms = and constructs as before. It=E2=80=99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin


I think that is fundamentally part= of the question:
We= are clear that we are producing a protocol that is
conceptually (if not= more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 b= ut with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 termi= nology, then we should not change the meanings of any definition. If we are= saying this supersedes or replaces what OAuth 2.0 creates, then we should = pick the best word for the job and ignore conflicting meanings from OAuth 2= .0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the = word just confuses everyone as everyone forgets the original meaning as new= documents come out, but the confusion with the use of a non-obvious word c= ontinues.

Food for thought.
- Warren
Warren Parad=
Founder, CTO
=
Secure your user data and complet= e your authorization architecture. Implement=C2=A0Authress.

=
On Tue= , Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
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/
--0000000000001134a605ac915483-- From nobody Mon Aug 10 20:58:36 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 5F4E73A09AF for ; Mon, 10 Aug 2020 20:58:35 -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 bsWENShre28r for ; Mon, 10 Aug 2020 20:58:34 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 BA0723A0985 for ; Mon, 10 Aug 2020 20:58:33 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id g75so1027316wme.4 for ; Mon, 10 Aug 2020 20:58:33 -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=H8sEN/EHDBMTUeN6HL+zP2HOVTu7ZudI3//COfkedvE=; b=BaBsCjGgSTZTL628a4J5SvtHowzgHyjZYt5FGdIsmeam0VKpccyuX5JWkbN1LRuq6w 9CL7bo+hfXarirjMLYuecMO4WpJbIXU7gtsQjaRccFo+G03FsEoBXll81qxvlHbExB59 iwUC/RS0hfOtOMDJFa4B0l4dJz1UNM3FKYROw= 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=H8sEN/EHDBMTUeN6HL+zP2HOVTu7ZudI3//COfkedvE=; b=CV/tfz7gpz7lImfF4aHuXftzwLaKNr1eP6sUi2LQfuVcRvLivVLw25sKNsFfFiDUv3 FDrug+nvxX1AO4Gc06dsyfRwEhgFVABGw7FlAJ0r3cjVakUy6sxUXuC0UOKUQQQ2ruRW njs87J1AeaNT1fgfm4OlxPL0rTT3r23ioQKGZ70UO4hgDcuWY4xF4JWYrf0JhM0w2z87 aHQgmGF0grx9pSUqIGVSqrEdUFew1CrqZLwPTbwar7cfSlCY2MHe/hyYuD4yf3tJhEbL BNE07JtUh9MjkSbNToLRA9lfQRYlmmS9o/Lav6bOEWfzta5ozosyxxNMkUHisSMPO8Re HgEg== X-Gm-Message-State: AOAM530D1QjeZK7eQ4JytljLvs3bBP3JGGovR69r5EgEfb0tfeRBEc3I TGWoPLxsDGcN46ZfRd0SOj1A6+cPEj0X85Eb+Sl75Q== X-Google-Smtp-Source: ABdhPJxGOp8XFtFPuyObQxhBGFQrmDDhJ9cRF/svGdxiDFOVOLHOYpmqKNuNXBCPJHNh3EUV8CJt7fN+aN6KC4BfWUY= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr1980754wml.38.1597118311642; Mon, 10 Aug 2020 20:58:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Mon, 10 Aug 2020 23:58:20 -0400 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a14bd405ac9215da" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 03:58:35 -0000 --000000000000a14bd405ac9215da Content-Type: text/plain; charset="UTF-8" Hello Denis, what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow: +-----------+ +--------------+ +-----------+ +----+ +---------------------+ | Requestor | | Orchestrator | | RS | | GS | | Resource Controller | | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | is | | Staff | | Registr. App | | Server | | AS | | Student | +-----------+ +--------------+ +-----------+ +----+ +---------------------+ |(1) RegisterStudent | | | | |---------------------->| | | | | |(2) RequestRecordIntent(RecordType,StudentId, | | OrchestratorId):AuthRequest[RecordType,StudentId] | |<-------------->| | | | | | | | | |(3) AuthZRequest(RecordType,StudentId,OrchestratorId) | |--------------------------->| | | | | |(4) ConsentRequest(RecordType, | | | | OrchestratorId):Consent | | | |<-------------->| | |(5) AuthZ[RecordType,StudentId,OrchestratorId] | |<---------------------------| | | | | | | | |(2) RequestRecord(RecordType,StudentId,OrchestratorId) | | :RecordOf[StudentId] | | | |<-------------->| | | |(7) Registered | | | | |<----------------------| | | | + + + + + we assume the authz request sent by "Client" to "AS" describes the protected resource without referring to the authz server. An AS can issue the authz to release the graduation record of a student ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to the target university. What matters for this authz object is: - StudentId: a reference to the student as known to the resource server. - RecordType: a reference to a resource of type graduation record as understandable by the resource server. - OrchestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator. But: - RS must trust AS issued token. - StudentId must be known to RS, AS and Orchestrator. Therefore, the AS does not need to know the RS. Keep the audience field empty. Same principle applies for the second use case. What privacy problem do you see here? Best regards. /Francis On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: > I tried my best twice to download three use cases in the Use cases > directory, but I failed. > > Rather than failing a third time, here is the direct link of the second > try: > > > https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) > > Denis > > > > > > > > -- > 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/ --000000000000a14bd405ac9215da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Denis,

what you describe in = the use case seems to be the default behavior of the protocol. Let me map i= t with this abstract protocol flow:

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-= ----------+ =C2=A0+----+ =C2=A0+---------------------+
| Requestor |=C2= =A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 = =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-------= ----+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+= =C2=A0+---------------------+
=C2=A0 |(1) RegisterStudent=C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|(2) RequestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Auth= Request[RecordType,StudentId]
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(RecordType,Stude= ntId,OrchestratorId)
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|--------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) Con= sentRequest(RecordType,
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Cons= ent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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=A0AuthZ[= RecordType,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--------------= -------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|(2) RequestRecord(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:Reco= rdOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Register= ed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------= ------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

we assume t= he authz request sent by "Client" to "AS" describes the= protected resource without referring=C2=A0to the authz server. An AS can i= ssue the authz to release the graduation record=C2=A0 of a student ((5)=C2= =A0AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to th= e target university.=C2=A0

What matters for this authz object= is:
- StudentId: a reference to = the student as known to the resource server.
- RecordType: a reference to a resource of type graduation reco= rd as understandable=C2=A0 by the resource server.
-=C2=A0OrchestratorId: reference to the Orchestrator. Can= be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2= =A0Orchestrator.

Therefore, the AS does not need to know the = RS. Keep the audience field empty.

Same principle applies for= the second use case.

=
What privacy problem do you see here?

Best regards.
/Fra= ncis

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-g= nap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along= -%22Privacy-by-Design%22-(PbD)

Denis







--
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/
--000000000000a14bd405ac9215da-- From nobody Mon Aug 10 22:52:44 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 13B6E3A0C8B for ; Mon, 10 Aug 2020 22:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 UD-fE1f5vMNB for ; Mon, 10 Aug 2020 22:52:27 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 7A9A83A0C86 for ; Mon, 10 Aug 2020 22:52:26 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id j9so9593554ilc.11 for ; Mon, 10 Aug 2020 22:52:26 -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=Y33gqiFsl14HWJmResNXfY0kWWq66IUl3R7MzJSR2pg=; b=nKNxpSS9rOiYQdgsC5nWrWbVTsF12t9iCWSxu8axu3MRMicWYmRyOb/sczzrolBtdA hfCR7LezcDSw74+/uP5Y3glPRgJFYF84HYCkLvNUw/SU8PcUMB5bXP09CUm1GoCzxco3 emO52S5Waqq7LgxzTDyLafFn++jS7Ii6ZMlySGvyoXINlmC+ZJQnOVE4vzhiEVSX/85i 05VpXNDdAwBkeopon2VyQZpwysafOsCn8E6Qb/kMt7DJDiGAC08WuMSbZGaljdXjCJFo bKZkPz278rwJzZQNG+lLlpfEEsffLfEoeF/+vjYLwr0O8L1AgMOfn1QHA8MJ+ckAiIkx exjQ== 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=Y33gqiFsl14HWJmResNXfY0kWWq66IUl3R7MzJSR2pg=; b=bBH3NvQHAnfzlp1R1XD2dCr4jeaknodJaUXtqvHoMTqd1qoowmwN/jAnyOEjJC66DV cHHdDsE09gbzEqGbnFEr1Udyh8Yz3W9GK7Bfkkv8aruLIkAAgu/qND/I3IzoxpOxMpcQ XL8EXb7rSHD46dxMR1ba2TSLu8FBS/hkXKqEzLlApfBzGyJZSV9HVViaupiqsZZItUBx xlcbHcZj1L4nuhNxh/trJI8eYDMBO7XXnoRcC1lXQjGWRwdcwAfSFIi2XKCrQGhbBPit HrbMDMOy1OLCUOppFYsM5mk47PLRlHG+/yEMv+dceWE96rigl07ilVjzqVaq64G9Bowt AHKQ== X-Gm-Message-State: AOAM532ZkcJg67NfqUlrRZP7JBUE4raAsqLlYPt70/onTg9ATWiinLKl 2AePYdjJPWfz94XP9bQ1UGQyua9uiXwBc79chFY= X-Google-Smtp-Source: ABdhPJzsaAFjT2eBl2P85Hj2Msbiqa6ycFPAkGVBzUoq6XqqFegLjSS1brwnVvDs8RAIPDSvA8fI7vY9a9rCeKDmXyM= X-Received: by 2002:a05:6e02:8:: with SMTP id h8mr19551662ilr.188.1597125145547; Mon, 10 Aug 2020 22:52:25 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> In-Reply-To: From: Fabien Imbault Date: Tue, 11 Aug 2020 07:52:15 +0200 Message-ID: To: Francis Pouatcha Cc: Dick Hardt , Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f65bce05ac93ac55" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 05:52:40 -0000 --000000000000f65bce05ac93ac55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, I like your proposal, seems much more intuitive. Fabien Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a= =C3=A9crit : > Hello Denis, Justin, Dick, Fabien, > > In this post ( > https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= ) > i suggested we use the word "Orchestrator" to designate the piece of > software that orchestrate interaction between "Requestor" (a.k.a. User), = AS > and RS to obtain the protected resource. > > We are turning around the same topic. As soon as we go beyond the origina= l > oAuth protocol, the word 'Client' becomes confusing. > > In the same response, I suggest we talk about "roles" and not "entities". > > Best regards. > /Francis > > On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: > >> I still think that client was the right name in OAuth 2, as the client >> wanted to do a client-server interaction, so the client used OAuth 2 to = get >> an access token to interact with the "server". >> >> I do agree that it is not the best term in GNAP. Primarily because GNAP >> is a combination of the client from OAuth 2, and the relying party from >> OIDC. >> >> /Dick >> =E1=90=A7 >> >> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >> >>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>> >>> >>> The term client in OAuth came from the computer science definition of >>> client-server interaction. >>> >>> >>> This, I would argue, is exactly why it=E2=80=99s a bad label for someth= ing >>> that=E2=80=99s distinctly more specific in this context, and I would lo= ve to see >>> GNAP adopt a more specific label for the role that we traditionally cal= led >>> =E2=80=9Cclient=E2=80=9D in OAuth. >>> >>> =E2=80=94 Justin >>> >>> >>> The client is getting an access token so it can call a server, >>> specifically, a resource server (to differentiate it from the authoriza= tion >>> server). >>> >>> The confusion in my experience usually stems from people working with >>> software that is acting in multiple roles. IE, the software that is act= ing >>> as a client in once context, is also acting as an RS in other contexts,= or >>> even acting as an AS. The other confusion is that people view clients a= s >>> being the software the user is using -- although it may not be acting a= s a >>> client in the oauth context. >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >>> wrote: >>> >>>> Hi, >>>> >>>> To me, client has always been a strange word in the context of OAuth, >>>> as it has a meaning well defined both in everyday life (this client is= a >>>> good customer) and in computer science (client-server interaction). Th= us I >>>> always have to make the mental translation to the OAuth world before a= ny >>>> discussion... And any teaching experience shows that it does make the >>>> concepts hard to grasp for a majority of (clever) people. >>>> >>>> As for the RO, previous discussions suggested Resource >>>> Controller (RC) also, which may be a bit more specific than manager. >>>> >>>> Fabien >>>> >>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>> >>>>> Justin and Dick, >>>>> >>>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>>> the creation of OAuth)"] >>>>> >>>>> So let us attempt to define new terms: >>>>> >>>>> *initiating application (IA)*: application by means of which a user >>>>> initiates interactions with RS(s) and AS(s) >>>>> >>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>> which is currently defined as: >>>>> >>>>> Resource Owner (RO): entity capable of granting access to a protected >>>>> resource >>>>> >>>>> I propose to replace it with Resource Manager (RM): >>>>> >>>>> *Resource Manager (RM)* : application or user that manages an access >>>>> decision function of a Resource Server >>>>> >>>>> Denis >>>>> >>>>> I agree with Justin. Redefining well used terms will lead to >>>>> significant confusion. If we have a different role than what we have = had >>>>> in the past, then that role should have a name not being used already= in >>>>> OAuth or OIDC. >>>>> >>>>> Given what we have learned, and my own experience explaining what a >>>>> Client is, and is not, improving the definition for Client could prov= e >>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>> >>>>> For example, clarifying that a Client is a role an entity plays in th= e >>>>> protocol, and that the same entity may play other roles at other time= s, or >>>>> some other language to help differentiate between "role" and "entity"= . >>>>> >>>>> /Dick >>>>> =E1=90=A7 >>>>> >>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>>>> >>>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a b= etter fit, but >>>>>> I=E2=80=99m not really in favor of taking an existing term and apply= ing a >>>>>> completely new definition to it. In other words, I would sooner stop= using >>>>>> =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and a= ccurate term for the >>>>>> role than to define =E2=80=9Cclient=E2=80=9D as meaning something co= mpletely different. We >>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the >>>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cser= ver=E2=80=9D on its own but instead >>>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>>> >>>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>>> ignore the fact that GNAP is going to be coming up in a world that i= s >>>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank >>>>>> slate to work with, but neither are we bound to use the same terms a= nd >>>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>>> >>>>>> I think that is fundamentally part of the question: >>>>>> >>>>>>> We are clear that we are producing a protocol that is >>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>> reusing terms >>>>>>> from OAuth 2.0 but with different definitions may lead to unnecessa= ry >>>>>>> confusion >>>>>> >>>>>> >>>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>>> should not change the meanings of any definition. If we are saying t= his >>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick t= he best >>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I h= ave a >>>>>> lot of first hand experience of industries "ruining words", and atte= mpting >>>>>> to side-step the problem rather than redefining the word just confus= es >>>>>> everyone as everyone forgets the original meaning as new documents c= ome >>>>>> out, but the confusion with the use of a non-obvious word continues. >>>>>> >>>>>> Food for thought. >>>>>> - Warren >>>>>> >>>>>> Warren Parad >>>>>> Founder, CTO >>>>>> Secure your user data and complete your authorization architecture. >>>>>> Implement Authress . >>>>>> >>>>>> >>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>>>> >>>>>>> Hi Denis, >>>>>>> >>>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>>> > Hi Justin, >>>>>>> > >>>>>>> > Since you replied in parallel, I will make a response similar to >>>>>>> the one >>>>>>> > I sent to Dick. >>>>>>> > >>>>>>> > > Hi Denis, >>>>>>> > > >>>>>>> > > I think there=E2=80=99s still a problem with the terminology in= use >>>>>>> here. What >>>>>>> > > you describe as RS2, which might in fact be an RS unto itself, >>>>>>> is a >>>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a cli= ent of RS1/. What >>>>>>> you >>>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth wo= rld, but it is >>>>>>> not at >>>>>>> > > all the same as an OAuth client. I appreciate your mapping of >>>>>>> the >>>>>>> > > entities below, but it makes it difficult to hold a discussion >>>>>>> if we >>>>>>> > > aren=E2=80=99t using the same terms. >>>>>>> > > >>>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG= we can >>>>>>> define >>>>>>> > > our own terms. The bad news is that this is really hard to do. >>>>>>> > > >>>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with n= ew >>>>>>> definitions, >>>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we d= efine >>>>>>> things. >>>>>>> > >>>>>>> > In the ISO context, each document must define its own terminology= . >>>>>>> The >>>>>>> > boiler plate for RFCs does not mandate a terminology or >>>>>>> definitions section >>>>>>> > but does not prevent it either. The vocabulary is limited and as >>>>>>> long as >>>>>>> > we clearly define what our terms are meaning, we can re-use a ter= m >>>>>>> already >>>>>>> > used in another RFC. This is also the ISO approach. >>>>>>> >>>>>>> Just because we can do something does not necessarily mean that it >>>>>>> is a >>>>>>> good idea to do so. We are clear that we are producing a protocol >>>>>>> that is >>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>> reusing terms >>>>>>> from OAuth 2.0 but with different definitions may lead to unnecessa= ry >>>>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>>>> Dick to >>>>>>> use the term "GS" in XAuth, picking a name that was not already use= d >>>>>>> in >>>>>>> OAuth 2.0. >>>>>>> >>>>>>> -Ben >>>>>>> >>>>>>> -- >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>> -- >> 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/ > --000000000000f65bce05ac93ac55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,

=
I like your proposal, seems much more intuitive.=C2=A0

Fabien=C2=A0
Le mar. = 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha <fpo@adorsys.de> a = =C3=A9crit=C2=A0:
= Hello Denis, Justin, Dick, Fabien,

In this post (https://mailarchive.iet= f.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) i suggested we use = the word "Orchestrator" to designate the piece of software that o= rchestrate interaction between "Requestor" (a.k.a. User), AS and = RS to obtain the protected resource.=C2=A0

We are = turning around the same topic. As soon as we go beyond=C2=A0the original oA= uth protocol, the word 'Client' becomes confusing.

In the same response, I suggest=C2=A0we talk about "roles&quo= t; and not "entities".

Best regards.
/Francis

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I still think that client was th= e right name in OAuth 2, as the client wanted to do a client-server interac= tion, so the client used OAuth 2 to get an access token to interact with th= e "server".

I do agree that it is not the = best term in GNAP. Primarily because GNAP is a combination of the client fr= om OAuth 2, and the relying party from OIDC.=C2=A0

/Dick
<= img alt=3D"" style=3D"width:0px;max-height:0px;overflow:hidden" src=3D"http= s://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&t= ype=3Dzerocontent&guid=3D62abdc1e-dee4-4043-9cd9-2a71280cbce4">=E1=90=A7

On Thu, Aug 6, 2020 at 12:50 PM = Justin Richer <jricher@mit.edu> wrote:
On Aug 6, 2020, at 12:53 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

The term client in OAuth c= ame from the computer science definition of client-server interaction.

This, I would argue, is exactly why= it=E2=80=99s a bad label for something that=E2=80=99s distinctly more spec= ific in this context, and I would love to see GNAP adopt a more specific la= bel for the role that we traditionally called =E2=80=9Cclient=E2=80=9D in O= Auth.

=C2=A0=E2=80=94 Justin


The client is getti= ng an access token so it can call a server, specifically, a resource server= (to differentiate it from the authorization server).

<= div>The confusion in my experience usually stems from people working=C2=A0w= ith software=C2=A0that is acting in multiple=C2=A0roles. IE, the software= =C2=A0that is acting as a client in once context, is also acting as an RS i= n other contexts, or even acting as an AS. The other confusion is that peop= le view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context.


3D""=E1=90=A7

On Thu, Aug 6, 2020 = at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
Hi,=C2=A0

To me, client has always been a s= trange word in the context of OAuth, as it has a meaning well defined both = in everyday life (this client is a good customer) and in computer science (= client-server interaction). Thus I always have to make the mental translati= on to the OAuth world before any discussion... And any teaching experience = shows that it does make the concepts hard to grasp for a majority of (cleve= r) people.

As for the RO, previous discussions sug= gested Resource Controller=C2=A0(RC)=C2=A0also, which may be a bit more spe= cific than manager.=C2=A0

Fabien=C2=A0
=
On Thu= , Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wr= ote:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

=
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mi= t.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://= www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
<= /div>
--000000000000f65bce05ac93ac55-- From nobody Mon Aug 10 23:17:31 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 F1AC63A0CC4 for ; Mon, 10 Aug 2020 23:17:28 -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_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 LAsSygh4jM1Z for ; Mon, 10 Aug 2020 23:17:27 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 25C9C3A0CC3 for ; Mon, 10 Aug 2020 23:17:27 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id q75so11522033iod.1 for ; Mon, 10 Aug 2020 23:17:27 -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=XtfgAYocZ7B3hzIoOQe7u50jZh6iMtD5NDUdrnl8Pv4=; b=rIHqW6Q57UEMCWs2sk4bJP2gzKmO07rYLHX3+3/WNC6lOWL0fjtHuUT1uzAOgS9Bal sQPdfNyhIuGcKI9migvNk1VuuzdDUCiTobGGe4iBq7W5Ie+CiCmMiPNg7F4EV9MPuh20 TJ7J+CfRkYKfHtCm9YNTIt3ScEG5QI3POmdMxKvlAcIDEgLhMor8HFBc/JG0FqsmZpJa GCz5ZPKdVVhgmDpdtdILWD0mUuhBkFlg8v0J4vbJxjB3V1vocQqXOnjJMCfVKSS4U/S0 1Ufa7WNOtJGN7EgJlOs+PR9TV2mPcoRPPTCDbkcLTF5q/7aG1i9rsz2oTpJZMtYcEeEC LjOg== 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=XtfgAYocZ7B3hzIoOQe7u50jZh6iMtD5NDUdrnl8Pv4=; b=fY9uPNuopZyoESAYvxGIJFfF+Wwd77W8oMw7fT5smZIylxUKmabQ83oPoC1nyjYHNP M+X46bYLu0IjYywG3sbgkOJUjkPS/j7te3IhhVM5TyupTTtCSrbsBjv6sGP0sM5NuVgs PbDbxBf22RwgHjENER42trM8VaqeXqxwfnCfZB5RjWcSP0OiC9idw1KNzo187aBxRE7M L2qjQvgHU35vrpFEdJLJI6Z7jLIr6juFXDkCuJA9+lDmtirIlQJ+5tC7A9byZomNtnYJ 3dBtriomIrb8klR0kG60NFIqtVJoLQ+RxUsL8KoIhBsrjErMIQ+KZT7sLQIQ4swD2FxB 422g== X-Gm-Message-State: AOAM530/hRYsfkgKOkXHT5vE+Au/kFXf5RC+1f4TpSDOT/SAO6KA2pKO 9cLdrAbHT02uz+BHAvmxTS7UY0KPAAK3oZGIDds= X-Google-Smtp-Source: ABdhPJyh0LwkzJIyLV1YGnKRfqiJAX5aO67xKDdFXN8Ff/nTWGodZELE8ppzvEEEGuojaqJjCVkt0wkaUNswb+fnm3c= X-Received: by 2002:a02:6c0d:: with SMTP id w13mr24449959jab.47.1597126645084; Mon, 10 Aug 2020 23:17:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Tue, 11 Aug 2020 08:17:14 +0200 Message-ID: To: Francis Pouatcha Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005774fb05ac94066b" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 06:17:29 -0000 --0000000000005774fb05ac94066b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked. Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not. I don't think the abstract flow deals with those privacy concerns. Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea. Fabien Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha a =C3=A9crit : > Hello Denis, > > what you describe in the use case seems to be the default behavior of the > protocol. Let me map it with this abstract protocol flow: > > +-----------+ +--------------+ +-----------+ +----+ > +---------------------+ > | Requestor | | Orchestrator | | RS | | GS | | Resource > Controller | > | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | is > | > | Staff | | Registr. App | | Server | | AS | | > Student | > +-----------+ +--------------+ +-----------+ +----+ > +---------------------+ > |(1) RegisterStudent | | | | > |---------------------->| | | | > | |(2) RequestRecordIntent(RecordType,StudentId, > | | > OrchestratorId):AuthRequest[RecordType,StudentId] > | |<-------------->| | | > | | | | | > | |(3) > AuthZRequest(RecordType,StudentId,OrchestratorId) > | |--------------------------->| | > | | | |(4) > ConsentRequest(RecordType, > | | | | > OrchestratorId):Consent > | | | |<-------------->| > | |(5) AuthZ[RecordType,StudentId,OrchestratorId] > | |<---------------------------| | > | | | | | > | |(2) > RequestRecord(RecordType,StudentId,OrchestratorId) > | | :RecordOf[StudentId] | | > | |<-------------->| | | > |(7) Registered | | | | > |<----------------------| | | | > + + + + + > > we assume the authz request sent by "Client" to "AS" describes the > protected resource without referring to the authz server. An AS can issue > the authz to release the graduation record of a student > ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference t= o > the target university. > > What matters for this authz object is: > - StudentId: a reference to the student as known to the resource server. > - RecordType: a reference to a resource of type graduation record as > understandable by the resource server. > - OrchestratorId: reference to the Orchestrator. Can be used to bind auth= z > to Orchestrator. > > But: > - RS must trust AS issued token. > - StudentId must be known to RS, AS and Orchestrator. > > Therefore, the AS does not need to know the RS. Keep the audience field > empty. > > Same principle applies for the second use case. > > What privacy problem do you see here? > > Best regards. > /Francis > > On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: > >> I tried my best twice to download three use cases in the Use cases >> directory, but I failed. >> >> Rather than failing a third time, here is the direct link of the second >> try: >> >> >> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cas= es-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >> >> Denis >> >> >> >> >> >> >> >> -- >> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005774fb05ac94066b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,

= I think Denis points to the fact that, in the current situation, the AS rec= eives the resource request from the Client and therefore knows what tokens = are asked. Then it also implements the consent interface (and possibly the = login too) and so it also knows who validates and what is accepted or not.<= /div>

I don't think the ab= stract flow deals with those privacy concerns.=C2=A0

Then I agree with you on the audience field of= the token, if left empty it simplifies part of the problem, although it re= moves a big part of the control you may want from directed tokens. That'= ;s why I'm willing to better develop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao= =C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> a =C3=A9crit= =C2=A0:
Hello=C2= =A0Denis,

what you describe in the use case seems to be = the default behavior of the protocol. Let me map it with this abstract prot= ocol flow:

+--------= ---+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ = =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orches= trator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| = Resource Controller |
| is UNIV-1= |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV= -0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|= =C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0= | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0= +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+-----------------= ----+
=C2=A0 |(1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |------= ---------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(R= ecordType,StudentId,
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest[RecordType,StudentId= ]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--------= ------>|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------------------= ->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->= ;|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,OrchestratorId= ]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordTy= pe,StudentId,OrchestratorId)
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= font face=3D"monospace">=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +

we assume the authz request sent by "= Client" to "AS" describes the protected resource without ref= erring=C2=A0to the authz server. An AS can issue the authz to release the g= raduation record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,StudentId,Or= chestratorId]), without any reference to the target university.=C2=A0

What matters for this authz object is:
- StudentId: a reference to the student as known to the reso= urce server.
- RecordType: a refe= rence to a resource of type graduation record as understandable=C2=A0 by th= e resource server.
-=C2=A0Orchest= ratorId: reference to the Orchestrator. Can be used to bind authz to Orches= trator.

But:
- RS m= ust trust AS issued token.
-=C2= =A0StudentId must be known to RS, AS and=C2=A0Orchestrator.

T= herefore, the AS does not need to know the RS. Keep the audience field empt= y.

Same principle applies for the second use case.

What privacy problem do you see here?

Best regards.
/Francis

On Tue, Aug 4, 20= 20 at 5:08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000005774fb05ac94066b-- From nobody Tue Aug 11 01:42:45 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 156F63A0E8F for ; Tue, 11 Aug 2020 01:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.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 mIwwJczSs0e3 for ; Tue, 11 Aug 2020 01:42:40 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 97F553A0E8D for ; Tue, 11 Aug 2020 01:42:40 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id h12so6378416pgm.7 for ; Tue, 11 Aug 2020 01:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4CyxAomWslM3Uv9ti8kbRYZpX+Yr178cxje3SwVnOos=; b=UHwJn/GMqINIGNAGG3aTpZRVIk1C8Y4O73rP7ZZH/0Boles/2QyYg33+c8bxGB0oYy U6Dg1/vaUZkaw7pmq4O3905IJf4nxljNQsiPebFAxvHabCYRRRKXZ7G4tv3ja7Er4UCl ZeEOv1XQEL6C43/rZDhzVm8Fid31uvKmGaqB0= 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=4CyxAomWslM3Uv9ti8kbRYZpX+Yr178cxje3SwVnOos=; b=B5nLElHavlHGk0nu9Do1/gC1GzBITwtySk6UJ2u9ebPv8L/g/07LphNAOOboECl3JQ yJ00XfALYuNSM3JCOm8cJaJ8ntwWgN6N+naIU55fRzxlF/q11UX+g8V4RVT0oB0X/7+/ ucKBq9gZiqm2fV2L4hWGIwURCXQ2C3s12GIOfNR8FixdVKzpg3ikEVAAjXX3ib1DJOqh SVyPgWzQ4J4eCwfQl1op0WSa8+eojbBlzEma5LSO8rBTsHyB3tfpqSlJ+YelOQShFbDG L/8Ro9uDHlI9+Z/LHvRVDzNL7VxQvz5fXWeDUmstjMgc7BG1t4ikP4s2dDXRHH2DG/6Q ZXQg== X-Gm-Message-State: AOAM531R924+yKmb2DKnrZvaNQZ3dxJ4VBgpvYvRg4CwdyeZl7+mLzpY bB0jDVb+IXrk24aXiuckOrDOCl6xysitNFFdM+FabI2MCUfDFiSKc+HnqQlyGop/uvda20BH+5c cCNa5zIcqxyKbAMA= X-Google-Smtp-Source: ABdhPJyvVxkf0FneollrhfENaaIX6l0Y4eAW7gy4prZicewKWhuR+oBWjjcoksSMv55wbLmSc/lLOocKCBYzEJpa8UA= X-Received: by 2002:a63:4c48:: with SMTP id m8mr25499633pgl.290.1597135359827; Tue, 11 Aug 2020 01:42:39 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> In-Reply-To: From: Dave Tonge Date: Tue, 11 Aug 2020 10:42:28 +0200 Message-ID: To: Fabien Imbault Cc: Francis Pouatcha , "txauth@ietf.org" , Denis , Benjamin Kaduk , Justin Richer , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000c803b205ac960d70" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 08:42:44 -0000 --000000000000c803b205ac960d70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all I agree that "client" can be confusing. I would be in support of alternative terminology. We can always have some wording that explains that an "Orchestrator" in GNAP plays a similar role to "Client" in OAuth. Dave On Tue, 11 Aug 2020 at 07:52, Fabien Imbault wrote: > Hi Francis, > > I like your proposal, seems much more intuitive. > > Fabien > > Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = a =C3=A9crit : > >> Hello Denis, Justin, Dick, Fabien, >> >> In this post ( >> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw= /) >> i suggested we use the word "Orchestrator" to designate the piece of >> software that orchestrate interaction between "Requestor" (a.k.a. User),= AS >> and RS to obtain the protected resource. >> >> We are turning around the same topic. As soon as we go beyond the >> original oAuth protocol, the word 'Client' becomes confusing. >> >> In the same response, I suggest we talk about "roles" and not "entities"= . >> >> Best regards. >> /Francis >> >> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: >> >>> I still think that client was the right name in OAuth 2, as the client >>> wanted to do a client-server interaction, so the client used OAuth 2 to= get >>> an access token to interact with the "server". >>> >>> I do agree that it is not the best term in GNAP. Primarily because GNAP >>> is a combination of the client from OAuth 2, and the relying party from >>> OIDC. >>> >>> /Dick >>> =E1=90=A7 >>> >>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >>> >>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>>> >>>> >>>> The term client in OAuth came from the computer science definition of >>>> client-server interaction. >>>> >>>> >>>> This, I would argue, is exactly why it=E2=80=99s a bad label for somet= hing >>>> that=E2=80=99s distinctly more specific in this context, and I would l= ove to see >>>> GNAP adopt a more specific label for the role that we traditionally ca= lled >>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> The client is getting an access token so it can call a server, >>>> specifically, a resource server (to differentiate it from the authoriz= ation >>>> server). >>>> >>>> The confusion in my experience usually stems from people working with >>>> software that is acting in multiple roles. IE, the software that is ac= ting >>>> as a client in once context, is also acting as an RS in other contexts= , or >>>> even acting as an AS. The other confusion is that people view clients = as >>>> being the software the user is using -- although it may not be acting = as a >>>> client in the oauth context. >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> To me, client has always been a strange word in the context of OAuth, >>>>> as it has a meaning well defined both in everyday life (this client i= s a >>>>> good customer) and in computer science (client-server interaction). T= hus I >>>>> always have to make the mental translation to the OAuth world before = any >>>>> discussion... And any teaching experience shows that it does make the >>>>> concepts hard to grasp for a majority of (clever) people. >>>>> >>>>> As for the RO, previous discussions suggested Resource >>>>> Controller (RC) also, which may be a bit more specific than manager. >>>>> >>>>> Fabien >>>>> >>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>>> >>>>>> Justin and Dick, >>>>>> >>>>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>>>> the creation of OAuth)"] >>>>>> >>>>>> So let us attempt to define new terms: >>>>>> >>>>>> *initiating application (IA)*: application by means of which a user >>>>>> initiates interactions with RS(s) and AS(s) >>>>>> >>>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>>> which is currently defined as: >>>>>> >>>>>> Resource Owner (RO): entity capable of granting access to a protecte= d >>>>>> resource >>>>>> >>>>>> I propose to replace it with Resource Manager (RM): >>>>>> >>>>>> *Resource Manager (RM)* : application or user that manages an access >>>>>> decision function of a Resource Server >>>>>> >>>>>> Denis >>>>>> >>>>>> I agree with Justin. Redefining well used terms will lead to >>>>>> significant confusion. If we have a different role than what we have= had >>>>>> in the past, then that role should have a name not being used alread= y in >>>>>> OAuth or OIDC. >>>>>> >>>>>> Given what we have learned, and my own experience explaining what a >>>>>> Client is, and is not, improving the definition for Client could pro= ve >>>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>>> >>>>>> For example, clarifying that a Client is a role an entity plays in >>>>>> the protocol, and that the same entity may play other roles at other= times, >>>>>> or some other language to help differentiate between "role" and "ent= ity". >>>>>> >>>>>> /Dick >>>>>> =E1=90=A7 >>>>>> >>>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote= : >>>>>> >>>>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but >>>>>>> I=E2=80=99m not really in favor of taking an existing term and appl= ying a >>>>>>> completely new definition to it. In other words, I would sooner sto= p using >>>>>>> =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and = accurate term for the >>>>>>> role than to define =E2=80=9Cclient=E2=80=9D as meaning something c= ompletely different. We >>>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the >>>>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient= =E2=80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cse= rver=E2=80=9D on its own but instead >>>>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and= =E2=80=9CResource Server=E2=80=9D. >>>>>>> >>>>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do >>>>>>> is ignore the fact that GNAP is going to be coming up in a world th= at is >>>>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t= have a blank >>>>>>> slate to work with, but neither are we bound to use the same terms = and >>>>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>>>> >>>>>>> I think that is fundamentally part of the question: >>>>>>> >>>>>>>> We are clear that we are producing a protocol that is >>>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>>> reusing terms >>>>>>>> from OAuth 2.0 but with different definitions may lead to >>>>>>>> unnecessary >>>>>>>> confusion >>>>>>> >>>>>>> >>>>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>>>> should not change the meanings of any definition. If we are saying = this >>>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick = the best >>>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I = have a >>>>>>> lot of first hand experience of industries "ruining words", and att= empting >>>>>>> to side-step the problem rather than redefining the word just confu= ses >>>>>>> everyone as everyone forgets the original meaning as new documents = come >>>>>>> out, but the confusion with the use of a non-obvious word continues= . >>>>>>> >>>>>>> Food for thought. >>>>>>> - Warren >>>>>>> >>>>>>> Warren Parad >>>>>>> Founder, CTO >>>>>>> Secure your user data and complete your authorization architecture. >>>>>>> Implement Authress . >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote= : >>>>>>> >>>>>>>> Hi Denis, >>>>>>>> >>>>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>>>> > Hi Justin, >>>>>>>> > >>>>>>>> > Since you replied in parallel, I will make a response similar to >>>>>>>> the one >>>>>>>> > I sent to Dick. >>>>>>>> > >>>>>>>> > > Hi Denis, >>>>>>>> > > >>>>>>>> > > I think there=E2=80=99s still a problem with the terminology i= n use >>>>>>>> here. What >>>>>>>> > > you describe as RS2, which might in fact be an RS unto itself, >>>>>>>> is a >>>>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a cl= ient of RS1/. >>>>>>>> What you >>>>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth w= orld, but it is >>>>>>>> not at >>>>>>>> > > all the same as an OAuth client. I appreciate your mapping of >>>>>>>> the >>>>>>>> > > entities below, but it makes it difficult to hold a discussion >>>>>>>> if we >>>>>>>> > > aren=E2=80=99t using the same terms. >>>>>>>> > > >>>>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new W= G we can >>>>>>>> define >>>>>>>> > > our own terms. The bad news is that this is really hard to do. >>>>>>>> > > >>>>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new >>>>>>>> definitions, >>>>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we = define >>>>>>>> things. >>>>>>>> > >>>>>>>> > In the ISO context, each document must define its own >>>>>>>> terminology. The >>>>>>>> > boiler plate for RFCs does not mandate a terminology or >>>>>>>> definitions section >>>>>>>> > but does not prevent it either. The vocabulary is limited and as >>>>>>>> long as >>>>>>>> > we clearly define what our terms are meaning, we can re-use a >>>>>>>> term already >>>>>>>> > used in another RFC. This is also the ISO approach. >>>>>>>> >>>>>>>> Just because we can do something does not necessarily mean that it >>>>>>>> is a >>>>>>>> good idea to do so. We are clear that we are producing a protocol >>>>>>>> that is >>>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>>> reusing terms >>>>>>>> from OAuth 2.0 but with different definitions may lead to >>>>>>>> unnecessary >>>>>>>> confusion. If I understand correctly, a similar reasoning prompte= d >>>>>>>> Dick to >>>>>>>> use the term "GS" in XAuth, picking a name that was not already >>>>>>>> used in >>>>>>>> OAuth 2.0. >>>>>>>> >>>>>>>> -Ben >>>>>>>> >>>>>>>> -- >>>>>>>> Txauth mailing list >>>>>>>> Txauth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> -- >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>> -- >>> 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/ >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000c803b205ac960d70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all

I agree that "= client" can be confusing. I would be in support of alternative termino= logy.
We can always have some wording that explains that an "Orch= estrator" in GNAP plays a similar role to "Client" in OAuth.=

Dave

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <= fabien.imbaul= t@gmail.com> wrote:
Hi Francis,

I like your proposal, seems much more intuitiv= e.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha <fpo@adorsys.de<= /a>> a =C3=A9crit=C2=A0:
Hello Denis, Justin, Dick, Fabien,

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JO= GNw/) i suggested we use the word "Orchestrator" to designate= the piece of software that orchestrate interaction between "Requestor= " (a.k.a. User), AS and RS to obtain the protected resource.=C2=A0

We are turning around the same topic. As soon as we g= o beyond=C2=A0the original oAuth protocol, the word 'Client' become= s confusing.

In the same response, I suggest=C2=A0= we talk about "roles" and not "entities".
Best regards.
/Francis

On Thu, Aug 6, 2020 at 6:= 36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I st= ill think that client was the right name in OAuth 2, as the client wanted t= o do a client-server interaction, so the client used OAuth 2 to get an acce= ss token to interact with the "server".

I = do agree that it is not the best term in GNAP. Primarily because GNAP is a = combination of the client from OAuth 2, and the relying party from OIDC.=C2= =A0

/Dick
3D""=E1=90=A7

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <jricher@mit.edu= > wrote:
=
On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gm= ail.com> wrote:

The term client in OAuth came from the computer science definition= of client-server interaction.

= This, I would argue, is exactly why it=E2=80=99s a bad label for something = that=E2=80=99s distinctly more specific in this context, and I would love t= o see GNAP adopt a more specific label for the role that we traditionally c= alled =E2=80=9Cclient=E2=80=9D in OAuth.

=C2=A0=E2= =80=94 Justin


The client is getting an access token so it can call a serv= er, specifically, a resource server (to differentiate it from the authoriza= tion server).

The confusion in my experience usual= ly stems from people working=C2=A0with software=C2=A0that is acting in mult= iple=C2=A0roles. IE, the software=C2=A0that is acting as a client in once c= ontext, is also acting as an RS in other contexts, or even acting as an AS.= The other confusion is that people view clients as being the software the = user is using -- although it may not be acting as a client in the oauth con= text.



3D""=E1=90=A7

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi,=C2=A0

To me, client has always been a strange word in the context of OAuth= , as it has a meaning well defined both in everyday life (this client is a = good customer) and in computer science (client-server interaction). Thus I = always have to make the mental translation to the OAuth world before any di= scussion... And any teaching experience shows that it does make the concept= s hard to grasp for a majority of (clever) people.

As for the RO, previous discussions suggested Resource Controller=C2=A0(RC= )=C2=A0also, which may be a bit more specific than manager.=C2=A0

Fabien=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <= denis.ietf@free.fr> wrote:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mi= t.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://= www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth


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


Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--000000000000c803b205ac960d70-- From nobody Tue Aug 11 03:43:08 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 0B1E43A0F84 for ; Tue, 11 Aug 2020 03:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 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, MALFORMED_FREEMAIL=1.573, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 U74KA_Q9xTGw for ; Tue, 11 Aug 2020 03:43:06 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 D92893A0F82 for ; Tue, 11 Aug 2020 03:43:05 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 3so2363497wmi.1 for ; Tue, 11 Aug 2020 03:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=EHWgIICEJhwlZmV8z0yB5kmQlf1bQSS5mmu/1vAW0N4=; b=KDnBCI1YfHoDZb7wER/KXSYAcoOhq/fjhvo0a8Al3m3snf/3KaeiIihmisTXAEXDDl EP91rNkIFOIlFI7TbYI0iCnsXV3Fmxe1s7Naa1ZIcwXGM0F72TLoTQ1a46lsKxmtyjMK MhjTYYgCowLPTqRuyo2dZd+Zm8WHYfw2RmUw2WxdkV8DA5uzQc28XCbZ7StLVFwvCR8T nAErYBh6oe4bZHDsfGCNUSJQmU9maIT5Fv+l+f0K7NeQ96YodhdnQDcZTIeRQz2K9POa HuVwNhXyRU6O4F4D0KazVH4dqju+JYzP9eMtFj7CWLXH5gvS1eW1A1U9qHFXMl8IRzeS vUuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=EHWgIICEJhwlZmV8z0yB5kmQlf1bQSS5mmu/1vAW0N4=; b=XwzVpBFlwL4VjcXn74tZ8A3Ln80o9d8O6IthGOz713aMZ/NomIsX9OkLmfi70PA9i/ YypbNcWhFptPc0jMR0brKwIaU74Otcn3eJSZnAn89jFXmXRbNUotOJw9YN+7I8qCFBPx t+VfCVtRk1qsevjUll7p7f+Z55iqKn/u+xsZQNDFvrKU2a0xri+4O5oqm0xp+WvBpVMA zXCuB3I4KbEdM6RX03MqhBtQz/lGZ43rwrrCU4ggVGlEWDpSbTKd9GWVP7KDNCrUUDGU Yc+xQigCsObjL7z0vnmgOEIPc0cFLTN6olu5xG5pmCTr+0nMj9nOZhmX18tPZb44hV5b NgxA== X-Gm-Message-State: AOAM532Pau9yRWq3J2wW31YRk4OyD8/RJR3o5PBNTYoRbHQDSqEygVNV 1HgaTZpwTMxf3bK7JI6IPD1/nsgDbemvpg== X-Google-Smtp-Source: ABdhPJzRyPBI0DAsedrR74AW0MuTMHZJXJsU/6sDJzQSJDXIPNbydTgOq4V/RIahH9pQeET7OsUG0w== X-Received: by 2002:a7b:c011:: with SMTP id c17mr3373441wmb.63.1597142584026; Tue, 11 Aug 2020 03:43:04 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id t3sm10164929wrx.5.2020.08.11.03.43.02 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 03:43:03 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Tue, 11 Aug 2020 13:43:01 +0300 From: Yaron Sheffer To: GNAP Mailing List Message-ID: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> Thread-Topic: Design team formed Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [GNAP] Design team formed 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, 11 Aug 2020 10:43:07 -0000 Thank you all for attending the inaugural GNAP meeting at IETF-108. We had quite a few volunteers, and the chairs picked the following people for the design team: * Kathleen Moriarty * Justin Richer * Dick Hardt * Mike Jones * Fabien Imbault Kathleen has graciously agreed to convene the sessions and report on the team's outcome. Thank you all who volunteered! We expect the design team to decide on a solution outline that combines the best of both proposals, and present this outline by Sep. 15. Anything is as usual subject to approval by the whole working group. Thanks, Leif and Yaron From nobody Tue Aug 11 08:44:29 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 955DE3A1116 for ; Tue, 11 Aug 2020 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 ZG9oC8BzJnKB for ; Tue, 11 Aug 2020 08:44:24 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 68AFB3A110D for ; Tue, 11 Aug 2020 08:44:24 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id e6so12617888oii.4 for ; Tue, 11 Aug 2020 08:44:24 -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=OmFGKUUm5hvywrnqUZoCQxu4i2NNKCSXxoQtMhOL8FQ=; b=HyS9xDjI6kf2B+z1sJLBajG3xAj4QKTSrSjqbhasYMQNWLd/m7ITPp4m7QYuhYPRzl qC+vZdJ0s85V078XC1fydXYQn6L5lpTrE+vDCM8iAwIZ2nE6wkxj5uLDs7a88eMU3Sl1 F8TauNOXha3gEgegNiGLlur2AxUniWfHJnYN1yKlBHrmiLMAP/rl5whuFQMlAR59//di 44kwUFql/WmrwHNNqIlp+e5AQUUo0533K4fWQh9GXA6LOCUW2L2A70N/eBbTHvPumlip iZtYppd+WV0iSRVUQLwOsHyBqAVb/3oEeOieKxNkl3Ynkgy1aUfJRHHQusLpIL1UJRsV 1iqA== 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=OmFGKUUm5hvywrnqUZoCQxu4i2NNKCSXxoQtMhOL8FQ=; b=RClLBBED5LiZizY12naf6HVaDsPu2p0h7JZRsw65bkk/EWueZ9nt9IsCd41S4Y3NFb GVMVwf6Se73xphmx0w/vmEfzrwNcACWwWPV3V4Wt6ILcS4DPcO4TGSEckzuHdZfNqxnD hIub9uukyQZmf5W27pM/nD6xao959vuNgZithpqJDzoo55W/M2CsXaKxvPDq085KJqSi Dpv37Q5A217MheyF4noc6EtUf8hjsGAO1uYwgVZw4+oPc/+FF8cnvpFvX8IRETaYOeZg yRHX/9q0iPci//7TkNurXT6fpMjpjNTVI7eMGs5g9+hnlP6g+zZbJOSlaEDuLeBwjS/V adpg== X-Gm-Message-State: AOAM532GhKAPStKMndrSRYQG51RseBh4RSR6UoNZJdguap9OZ6M2EqiN sX0zioNtbZ1wPYLWJDl2Od+xCA02/5PSrLVRZRk= X-Google-Smtp-Source: ABdhPJwI5zVGgdgdY2Rx/OCEMs8vQ30JbHvemjnLl5VU5dngv5jaT+yxfjPdhOjJqmhbxx6kB3pEICKMxXHckt5rEM4= X-Received: by 2002:aca:309:: with SMTP id 9mr4159778oid.131.1597160663534; Tue, 11 Aug 2020 08:44:23 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <401b5e1e-7e6a-87c7-393b-51aaeed5fe0c@free.fr> <00EFDCE5-513D-449A-A1B6-BE1905E3D8A3@mit.edu> In-Reply-To: From: Tom Jones Date: Tue, 11 Aug 2020 08:44:12 -0700 Message-ID: To: Dave Tonge Cc: Fabien Imbault , Francis Pouatcha , Justin Richer , Benjamin Kaduk , "txauth@ietf.org" , Denis , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000ffe43105ac9bf13b" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 15:44:28 -0000 --000000000000ffe43105ac9bf13b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable the term "orchestator" does not match any use case i have. Let's be clear that there are four entities to a single transaction in the real world sense of things. (and others that support the transaction.) Then we can focus on the end point roles. I will focus on the data privacy issues, API's have the same parties with different terminology. 1. the subject of the data to be transferred. 2. the user of a grant from the subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the user= ) 3. the site that has a repository of user data with legal obligations to protect that data (the GDPR) (role resource server.) 4 the site that wants either access to the data, or some privacy preserving statement about the existence and content of the data. (role of client, vendor, PISP, etc.) 5. some sorts of facilitator sites for allowing access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been left out of OAUTH for good reason. This is a note supporting the separation of roles from legal entities. BTW, I firmly believe that the legal entity also needs to be ID'd by the transaction. Peace ..tom On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge wrote: > Hi all > > I agree that "client" can be confusing. I would be in support of > alternative terminology. > We can always have some wording that explains that an "Orchestrator" in > GNAP plays a similar role to "Client" in OAuth. > > Dave > > On Tue, 11 Aug 2020 at 07:52, Fabien Imbault > wrote: > >> Hi Francis, >> >> I like your proposal, seems much more intuitive. >> >> Fabien >> >> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a =C3=A9crit : >> >>> Hello Denis, Justin, Dick, Fabien, >>> >>> In this post ( >>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGN= w/) >>> i suggested we use the word "Orchestrator" to designate the piece of >>> software that orchestrate interaction between "Requestor" (a.k.a. User)= , AS >>> and RS to obtain the protected resource. >>> >>> We are turning around the same topic. As soon as we go beyond the >>> original oAuth protocol, the word 'Client' becomes confusing. >>> >>> In the same response, I suggest we talk about "roles" and not "entities= ". >>> >>> Best regards. >>> /Francis >>> >>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: >>> >>>> I still think that client was the right name in OAuth 2, as the client >>>> wanted to do a client-server interaction, so the client used OAuth 2 t= o get >>>> an access token to interact with the "server". >>>> >>>> I do agree that it is not the best term in GNAP. Primarily because GNA= P >>>> is a combination of the client from OAuth 2, and the relying party fro= m >>>> OIDC. >>>> >>>> /Dick >>>> =E1=90=A7 >>>> >>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >>>> >>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>>>> >>>>> >>>>> The term client in OAuth came from the computer science definition of >>>>> client-server interaction. >>>>> >>>>> >>>>> This, I would argue, is exactly why it=E2=80=99s a bad label for some= thing >>>>> that=E2=80=99s distinctly more specific in this context, and I would = love to see >>>>> GNAP adopt a more specific label for the role that we traditionally c= alled >>>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> The client is getting an access token so it can call a server, >>>>> specifically, a resource server (to differentiate it from the authori= zation >>>>> server). >>>>> >>>>> The confusion in my experience usually stems from people working with >>>>> software that is acting in multiple roles. IE, the software that is a= cting >>>>> as a client in once context, is also acting as an RS in other context= s, or >>>>> even acting as an AS. The other confusion is that people view clients= as >>>>> being the software the user is using -- although it may not be acting= as a >>>>> client in the oauth context. >>>>> >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> To me, client has always been a strange word in the context of OAuth= , >>>>>> as it has a meaning well defined both in everyday life (this client = is a >>>>>> good customer) and in computer science (client-server interaction). = Thus I >>>>>> always have to make the mental translation to the OAuth world before= any >>>>>> discussion... And any teaching experience shows that it does make th= e >>>>>> concepts hard to grasp for a majority of (clever) people. >>>>>> >>>>>> As for the RO, previous discussions suggested Resource >>>>>> Controller (RC) also, which may be a bit more specific than manager. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>>>> >>>>>>> Justin and Dick, >>>>>>> >>>>>>> [Was: "Revisiting the photo sharing example (a driving use case fo= r >>>>>>> the creation of OAuth)"] >>>>>>> >>>>>>> So let us attempt to define new terms: >>>>>>> >>>>>>> *initiating application (IA)*: application by means of which a user >>>>>>> initiates interactions with RS(s) and AS(s) >>>>>>> >>>>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>>>> which is currently defined as: >>>>>>> >>>>>>> Resource Owner (RO): entity capable of granting access to a >>>>>>> protected resource >>>>>>> >>>>>>> I propose to replace it with Resource Manager (RM): >>>>>>> >>>>>>> *Resource Manager (RM)* : application or user that manages an >>>>>>> access decision function of a Resource Server >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> I agree with Justin. Redefining well used terms will lead to >>>>>>> significant confusion. If we have a different role than what we hav= e had >>>>>>> in the past, then that role should have a name not being used alrea= dy in >>>>>>> OAuth or OIDC. >>>>>>> >>>>>>> Given what we have learned, and my own experience explaining what a >>>>>>> Client is, and is not, improving the definition for Client could pr= ove >>>>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>>>> >>>>>>> For example, clarifying that a Client is a role an entity plays in >>>>>>> the protocol, and that the same entity may play other roles at othe= r times, >>>>>>> or some other language to help differentiate between "role" and "en= tity". >>>>>>> >>>>>>> /Dick >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a= better fit, but >>>>>>>> I=E2=80=99m not really in favor of taking an existing term and app= lying a >>>>>>>> completely new definition to it. In other words, I would sooner st= op using >>>>>>>> =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and= accurate term for the >>>>>>>> role than to define =E2=80=9Cclient=E2=80=9D as meaning something = completely different. We >>>>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the >>>>>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient= =E2=80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cs= erver=E2=80=9D on its own but instead >>>>>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D an= d =E2=80=9CResource Server=E2=80=9D. >>>>>>>> >>>>>>>> GNAP can do something similar, in my opinion. But what we can=E2= =80=99t do >>>>>>>> is ignore the fact that GNAP is going to be coming up in a world t= hat is >>>>>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank >>>>>>>> slate to work with, but neither are we bound to use the same terms= and >>>>>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>>>>> >>>>>>>> =E2=80=94 Justin >>>>>>>> >>>>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>>>>> >>>>>>>> I think that is fundamentally part of the question: >>>>>>>> >>>>>>>>> We are clear that we are producing a protocol that is >>>>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>>>> reusing terms >>>>>>>>> from OAuth 2.0 but with different definitions may lead to >>>>>>>>> unnecessary >>>>>>>>> confusion >>>>>>>> >>>>>>>> >>>>>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>>>>> should not change the meanings of any definition. If we are saying= this >>>>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick= the best >>>>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I= have a >>>>>>>> lot of first hand experience of industries "ruining words", and at= tempting >>>>>>>> to side-step the problem rather than redefining the word just conf= uses >>>>>>>> everyone as everyone forgets the original meaning as new documents= come >>>>>>>> out, but the confusion with the use of a non-obvious word continue= s. >>>>>>>> >>>>>>>> Food for thought. >>>>>>>> - Warren >>>>>>>> >>>>>>>> Warren Parad >>>>>>>> Founder, CTO >>>>>>>> Secure your user data and complete your authorization architecture= . >>>>>>>> Implement Authress . >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Denis, >>>>>>>>> >>>>>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>>>>> > Hi Justin, >>>>>>>>> > >>>>>>>>> > Since you replied in parallel, I will make a response similar t= o >>>>>>>>> the one >>>>>>>>> > I sent to Dick. >>>>>>>>> > >>>>>>>>> > > Hi Denis, >>>>>>>>> > > >>>>>>>>> > > I think there=E2=80=99s still a problem with the terminology = in use >>>>>>>>> here. What >>>>>>>>> > > you describe as RS2, which might in fact be an RS unto itself= , >>>>>>>>> is a >>>>>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a c= lient of RS1/. >>>>>>>>> What you >>>>>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is >>>>>>>>> not at >>>>>>>>> > > all the same as an OAuth client. I appreciate your mapping of >>>>>>>>> the >>>>>>>>> > > entities below, but it makes it difficult to hold a discussio= n >>>>>>>>> if we >>>>>>>>> > > aren=E2=80=99t using the same terms. >>>>>>>>> > > >>>>>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can >>>>>>>>> define >>>>>>>>> > > our own terms. The bad news is that this is really hard to do= . >>>>>>>>> > > >>>>>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with= new >>>>>>>>> definitions, >>>>>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we= define >>>>>>>>> things. >>>>>>>>> > >>>>>>>>> > In the ISO context, each document must define its own >>>>>>>>> terminology. The >>>>>>>>> > boiler plate for RFCs does not mandate a terminology or >>>>>>>>> definitions section >>>>>>>>> > but does not prevent it either. The vocabulary is limited and a= s >>>>>>>>> long as >>>>>>>>> > we clearly define what our terms are meaning, we can re-use a >>>>>>>>> term already >>>>>>>>> > used in another RFC. This is also the ISO approach. >>>>>>>>> >>>>>>>>> Just because we can do something does not necessarily mean that i= t >>>>>>>>> is a >>>>>>>>> good idea to do so. We are clear that we are producing a protoco= l >>>>>>>>> that is >>>>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>>>> reusing terms >>>>>>>>> from OAuth 2.0 but with different definitions may lead to >>>>>>>>> unnecessary >>>>>>>>> confusion. If I understand correctly, a similar reasoning >>>>>>>>> prompted Dick to >>>>>>>>> use the term "GS" in XAuth, picking a name that was not already >>>>>>>>> used in >>>>>>>>> OAuth 2.0. >>>>>>>>> >>>>>>>>> -Ben >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Txauth mailing list >>>>>>>>> Txauth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>> -- >>>>>>>> Txauth mailing list >>>>>>>> Txauth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> >>>>> -- >>>> 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/ >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ffe43105ac9bf13b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
the term "orchestator" does not match any u= se case i have.
Let's be clear that there are four entities t= o a single transaction in the real world sense of things. (and others that = support the=C2=A0 transaction.)
Then we can focus on the end = point roles. I will focus on the data privacy issues, API's have the sa= me parties with different terminology.
1. the subject of the = data to be transferred.
2. the user of a grant from the subject t= o act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to e= nable the user)
3. the site that has a repository of user data wi= th legal obligations to protect that data (the GDPR) (role resource server.= )
4 the site that wants either access to the data, or some pr= ivacy preserving statement about the existence and content of the data. (ro= le of client, vendor, PISP, etc.)
5. some sorts of facilitato= r sites for allowing access (roles like authenticator, idp, verifier, csp, = RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

This is a note supporting the separation of roles from= legal entities.=C2=A0 BTW, I firmly believe that the legal entity also nee= ds to be ID'd by the transaction.
Peace ..tom


=
On Tue, Au= g 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
Hi all
<= div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-serif"><= br>
I agree that "client" can be confusing. I would be in su= pport of alternative terminology.
We can always have some wording th= at explains that an "Orchestrator" in GNAP plays a similar role t= o "Client" in OAuth.

Dave

On Tue, 11 Aug 2020= at 07:52, Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I like your prop= osal, seems much more intuitive.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Fr= ancis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:
Hello Denis, Jus= tin, Dick, Fabien,

In this post (https://mailarchive.ietf.org/arch/msg/t= xauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) i suggested we use the word "O= rchestrator" to designate the piece of software that orchestrate inter= action between "Requestor" (a.k.a. User), AS and RS to obtain the= protected resource.=C2=A0

We are turning around t= he same topic. As soon as we go beyond=C2=A0the original oAuth protocol, th= e word 'Client' becomes confusing.

In the = same response, I suggest=C2=A0we talk about "roles" and not "= ;entities".

Best regards.
/Francis<= /div>

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@= gmail.com> wrote:
I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

I do agree that it is not the best term in GN= AP. Primarily because GNAP is a combination of the client from OAuth 2, and= the relying party from OIDC.=C2=A0

/Dick
3D""=E1=90=A7

On Thu, Aug 6, 2020 at 12:50 PM Justin Ri= cher <jricher@mit.edu> wrote:
On Aug 6, 2020, at 12:53 PM, Dick Har= dt <dick.hardt@gmail.com> wrote:

The term client in OAuth came from= the computer science definition of client-server interaction.
<= /blockquote>

This, I would argue, is exactly why it=E2= =80=99s a bad label for something that=E2=80=99s distinctly more specific i= n this context, and I would love to see GNAP adopt a more specific label fo= r the role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.<= /div>

=C2=A0=E2=80=94 Justin


The client is getting a= n access token so it can call a server, specifically, a resource server (to= differentiate it from the authorization server).

= The confusion in my experience usually stems from people working=C2=A0with = software=C2=A0that is acting in multiple=C2=A0roles. IE, the software=C2=A0= that is acting as a client in once context, is also acting as an RS in othe= r contexts, or even acting as an AS. The other confusion is that people vie= w clients as being the software the user is using -- although it may not be= acting as a client in the oauth context.



3D""=E1=90=A7

On Thu, Aug 6, 2020 = at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
Hi,=C2=A0

To me, client has always been a s= trange word in the context of OAuth, as it has a meaning well defined both = in everyday life (this client is a good customer) and in computer science (= client-server interaction). Thus I always have to make the mental translati= on to the OAuth world before any discussion... And any teaching experience = shows that it does make the concepts hard to grasp for a majority of (cleve= r) people.

As for the RO, previous discussions sug= gested Resource Controller=C2=A0(RC)=C2=A0also, which may be a bit more spe= cific than manager.=C2=A0

Fabien=C2=A0
=
On Thu= , Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wr= ote:
=20 =20 =20
Justin and Dick,

[Was:=C2=A0 "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

So let us attempt to define new terms:
initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
R= esource Owner (RO): entity capable of granting access to a protected resource<= /div>
I propose to replace it with Resource Manager (RM):
Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
Denis

=20
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have = a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""==E1=90=A7

On Wed, Aug 5, 2020 at 8:20 A= M Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m= not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a n= ew, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning something completely differ= ent. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all,= nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifie= s it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Se= rver=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is going to = be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to w= ork with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
W= e are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words= ", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren = Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Tue, Aug 4= , 2020 at 8:53 PM Benjamin Kaduk <kaduk@mi= t.edu> wrote:
H= i Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem= with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth parla= nce because it is /a client of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D ha= s no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms. > >
> > The good news is that this isn=E2=80=99= t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-u= se existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be mo= re precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we ar= e producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a n= ame that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://= www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth


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


Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ffe43105ac9bf13b-- From nobody Tue Aug 11 09:14:41 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 4D67C3A115C for ; Tue, 11 Aug 2020 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=microsoft.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 kYAy7h1lzY4O for ; Tue, 11 Aug 2020 09:14:34 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650101.outbound.protection.outlook.com [40.107.65.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF98C3A081C for ; Tue, 11 Aug 2020 09:14:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=beTYc3Fj0xdmqP+e9E7qfFDtJ/RWE/5SfrIcDZsIVOhPupz9Jiw2gHbf8qNqzuAfRrwM8TdpPRxg3PqFNFPsMJ3w0KeRT0ro2WPCr3ab+w6d0lyud4OZBdi7GHP8htGKIt2agEjdydPhOQb4/Y5yxPd24ItDWBVp3cPiMsGFAdtMIKZHO4G6mzdeb0phYCFnQ/jz+QMI/N4l1nyNEtxRAiiSZcxRgmfCO5e+Tsm/gVtX3pcNBEWWGv+hZ+EXbP5383sP1imI6T+pu3YnKIY/4QsZJUbl7yFdpmk794EQp+fidb5WlrZAxE3PCPYa8wCxMlFKqRdzG0pE5bbLNv94Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1LDpLQ9Btp6bAUlRGi5rp73oUUpbTq9xW87/9E77K0s=; b=cMfatHMwoIXNLLwxaeufW1Q5Xz7GxcDH6ioqkz//T46AqY74EXmCnPqTLRzg1dZem8rwJSoYQTbFq7YlTVPhydUyEOg5LuQhWzl81CtR5ZhhkGNJqUGE7uL5Mte35ra5z5AIORisWaUBzPxlOgTioxvCKdDgnqHiw58de+q4DqZiAXWIUad+plN7DQuaB6EZojJVxYJNUvuYfliQD2Ah5b7t/fYlmYOqRp3skoxQ1kzeoz1y+6AGOd8UWol3h17jOFtzJoKp71k/K9iFtbjy78dfMCRSIEdtKlpcKm8mM4IFn72YzkxCLHYL8Edq9PkcXVmzlweoeBlzKbL3iwSUsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1LDpLQ9Btp6bAUlRGi5rp73oUUpbTq9xW87/9E77K0s=; b=QJ7B1l5QWRC4NhQoqpkj/JwaRzl7qPGEXZBJUGhr7Y7Z9DGkleZC+tS/4vo856W8zXjtpYybcEhYX36ruS4OaCN/jvmdnR71YiFI7MLkYfmkO+mj5GDShYLgSAWztH7EDKLWoYSkEgXo3qSRIgZoAGNlvRimLeo55GM6Wl+GB+g= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0783.namprd00.prod.outlook.com (2603:10b6:5:1bd::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3321.0; Tue, 11 Aug 2020 16:14:31 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::d453:df4b:be59:8bd]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::d453:df4b:be59:8bd%3]) with mapi id 15.20.3321.000; Tue, 11 Aug 2020 16:14:31 +0000 From: Mike Jones To: Yaron Sheffer , GNAP Mailing List Thread-Topic: Design team formed Thread-Index: AQHWb8w5keioncSjfE+8Y8dh7sZoNqkzFOig Date: Tue, 11 Aug 2020 16:14:30 +0000 Message-ID: References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> In-Reply-To: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-11T16:12:47Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=287adbc5-e364-412d-9c2e-ed6a9e89d312; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 619cd23b-7d0b-4dc9-b010-08d83e11a112 x-ms-traffictypediagnostic: DM6PR00MB0783: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b5c5WZmi/SMympJckoiiYHch5wYiN4n7+yFa3N3LpYSiyekn66WFBa+LIDWsq0KbHg2IoT/csp0/biHcLPvPgBmJypT/F7xhBWaGjBTDsQPMktKCsWueo7TNvhna0Ur6VnUXXYayZLKx9hajzB9VXmYJ0EdLd+GYi0ktWvdgFPQMsHX4s5yUGw3ZVkU/Wcw5FTQQ6o5zJTClwr0VvTexANr1WVvIADfU6wfsbZhB9DQR3YKg3yitLhxbUxStnpewFCB6iRzkdLxs4+OMIYJiIIK67Is5ViQuFin02DJkjUGD32Mg5zm+3feNCD/85UVXujOwjL8mGdJb3zIXh0EKnGkXb4zZgnfxL1mg0i0i02tZR2YyWilMn6NJLnEbk4AleXkhxc6olhaa3o1KDZMW2Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(346002)(39860400002)(396003)(366004)(66476007)(6506007)(76116006)(66946007)(64756008)(7696005)(66556008)(2906002)(186003)(82960400001)(82950400001)(10290500003)(52536014)(66446008)(53546011)(8676002)(8936002)(33656002)(5660300002)(7116003)(8990500004)(26005)(110136005)(71200400001)(3480700007)(316002)(478600001)(86362001)(966005)(83380400001)(55016002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: OjNdPBMXEkifNdSm4UbL3fWnf+LjV4EdUQaICRgjLoiVpOkxfi3zpKk4FuIwjH3UID/4miLLYDDYcs+Rz4KAbq5XRgtjFIfdwaCHXU/IlcdNB3jsf4LtTUYUJbigMn2LdmGXBVIrkWOD3wa9BVvyahppYFDftKReGx9ZyzBdKb6wlyuNbhwYUksQyEIA9M0LysLTlgKl5weYqlUIImwGaDBrxhGVSvNk0/rJWOdzobOnzwZbP8afhktVvrNX5+LuKAOlzItMhDoYOH8JK7Cn4m3zm0RyvvRE9dgBFRyKgmOX4jk+YKx4We3406PIWIXAnOktHINAzfFNSW124zJqrcLNQNIXYC6NoxPaIJEC3Zm6VGoliSgxbIVv1oDryvn+4K8QS6PpJR3zmwWZsRLNf4IDlwYfKeVKJeY0oI9wTITclXCKowv+gV3Ov7qJ38edxFNK5Tl23qwDU3vNSMvMUXz/yr1vSgTH/Ceb204UzpU2vQkZA9j1BTCqD14fyo1hRfE5KtTT6dj0loP02JJq/2FsoZQe5R7ooiZAY77BnoUpKcobw3HZqSi8orjtGzt2PGo3A447kTRpb+Ov1MBtVgn05snevLJ/RPzSy/GgFIZew9guMvmonSua35oVXnjr/hlPUg7pyLy0RejWozW4Qg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 619cd23b-7d0b-4dc9-b010-08d83e11a112 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 16:14:30.9642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yKeyoLpmPC2Ku/91QjJe1CyZQZtBIHNwcoHbd09CelLN6giPPVhwMaHgW0/PvCd96KiLvYp1N40OMwyEd2oiaA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0783 Archived-At: Subject: Re: [GNAP] Design team formed 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, 11 Aug 2020 16:14:41 -0000 Thanks for your confidence in me and the rest of the design team. I plan t= o read both individual specs cover-to-cover as part of my preparation for t= his work. Dick and Justin, are there additional edits you plan to publish before I sh= ould do my review, or should I review the currently published drafts? Thanks, -- Mike -----Original Message----- From: TXAuth On Behalf Of Yaron Sheffer Sent: Tuesday, August 11, 2020 3:43 AM To: GNAP Mailing List Subject: [GNAP] Design team formed Thank you all for attending the inaugural GNAP meeting at IETF-108. We had = quite a few volunteers, and the chairs picked the following people for the = design team: * Kathleen Moriarty * Justin Richer * Dick Hardt * Mike Jones * Fabien Imbault Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered! We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group. Thanks, Leif and Yaron --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Aug 11 09:33:29 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 1945B3A0544 for ; Tue, 11 Aug 2020 09:33:28 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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=microsoft.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 2ZCnaR1Zd9M9 for ; Tue, 11 Aug 2020 09:33:24 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650095.outbound.protection.outlook.com [40.107.65.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAF53A044E for ; Tue, 11 Aug 2020 09:33:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kCaKRhwZTzoBKo2pUTXzgAbNFKjWy1q4FqXvmksMoxp43nPG/jMQkMWj5zRzXt97orBZVFaz+weZxKFla57Wp80IH7vxE+Q8JT0+HfAQ6Hffe0d7yR5mEwjLxdhDA8vRlq85jqzOEbfZALjQraDS37VMYyYofo/CwZ7GyS2N4NRTkbD8jRFRJbCDSbW8bZHWqTMZZJPNFziBtHkIjGIaknsXrPfQH7UHTE9G4xlgWZAgKZy2QIb4PHBQq++t/1uYlLcJPnDx6tXZEGZU6ldEjfPaU+oEn+Y0sm4qAGAzJeyUqFfaVzEfvH50iy8IBcBfEO5sM/f/NZd8EXvlRG3JLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/2E7GTtc8Q8DBnnE3uP4V+0SPSYZ8OR4uPehwBPA3Pc=; b=Nzd7tgV5Gf1dzp076NPcl6iqJY4WL9E+a2hlSarzqvD5PS/ziMvdGfM5pA6hoR2MSZ160G1fQoblyh4kSbyjRmtVAXe+kYJ61v+jZQty1dt51M6WO81o9gGSC92gnD4ekY1cQeHIExogjNrcr3wGd717YjX3rBI+Nr+PqTddSp8RXn9V4OBFilWs98IcVR1vvZ+Yzd1d2M6ujbE/dAQ+IspOMYp3MACIZQ19dyLQMUbXGgj0xHEqxXg2vE+lEJreLsvwWBWKeLGZXc0Hoem/FpZe06O4USowhh1ZZKXCjgEksuCnqs0jb9h0dvI+J2xJf4frHCE5Zhd2MJmBu7BxlQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/2E7GTtc8Q8DBnnE3uP4V+0SPSYZ8OR4uPehwBPA3Pc=; b=QnFcKxQKlEDyWsKKcd1H1RFue8UcjYinPaaFN2Gx7k67GLZDfNCJS+ic2vFATtFvwpWRxObbT+oEVAcXU2QQ0ycbJkPgQ12HJoItvHdk8o7p5m7wLc6FHEB22KP9hvi24+UjYrsw5RTWKBex5O1UE1ISYuA+OG5EoY8uSUq8FgI= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0555.namprd00.prod.outlook.com (2603:10b6:5:165::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3319.0; Tue, 11 Aug 2020 16:33:21 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::d453:df4b:be59:8bd]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::d453:df4b:be59:8bd%3]) with mapi id 15.20.3321.000; Tue, 11 Aug 2020 16:33:21 +0000 From: Mike Jones To: Tom Jones , Dave Tonge CC: Francis Pouatcha , Justin Richer , Dick Hardt , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" Thread-Topic: [GNAP] Terminology Thread-Index: AdZv/R57SuqhVoCLSASsMKlwQBhwaw== Date: Tue, 11 Aug 2020 16:33:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-11T16:30:09Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ae3f2c61-9dc1-44d9-a72c-831ee423701b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 525ab8a0-5fc7-408e-ac3b-08d83e144304 x-ms-traffictypediagnostic: DM6PR00MB0555: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:619; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: p0yRuWSdMgM6TYN/HOrIocgvQ50mxg38QFHfIERwcgEy01x5EKVNnbXPemj7QHXFEN7sWFr2Nb6/AaVUu3JQfO6bGHKxiKZ3ewtvzXDAngAut4Dx8pvJYWPkrnIpofQjhua27+NFVMocvLcl5XqlcEylZvo3gg27yyJX5dd5eZ0tvZCNgCQzgF67YnBUjFL2/Dsyq0pWxQf1j6pQS2FXzPz6UH7DL4pb/McLJtvGqD/yt1o+JNzlu6hCToY1ccWjDMl3Cb78EvbqSQVhY4UEJIZAx6etyH7qtfshc+Lv8CfIyrUj5tNJ6lGXmIQyxztWFK+Si8FTlqzJ/eICfUibJE0RhbnfGjIQ+8iCLCR4Y0tGr7bZeMVWVV7B55KWYu+2YQFQQaAcv5biY7a3cknkDuOfMTXmKDyNNEcI5P8BMZaWfsWm+68G8s5r8tRMZHMhqKoLHhNSbhljiWV95YDiJGDDo63F4+QRIkCqITpG2yk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(136003)(376002)(396003)(366004)(110136005)(76116006)(54906003)(5660300002)(33656002)(66446008)(4326008)(316002)(64756008)(166002)(66476007)(66946007)(83080400001)(83380400001)(55016002)(76236003)(30864003)(66556008)(66574015)(8990500004)(71200400001)(82960400001)(16799955002)(52536014)(966005)(9686003)(82950400001)(8676002)(186003)(7696005)(26005)(2906002)(53546011)(6506007)(8936002)(10290500003)(86362001)(478600001)(99710200001)(15866825006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: AEK7sA7qMd9I2/n+A3UMs5qiaMjv6W0KVeBQjDYyZftyl5R3mf0DfJTIwgGKZV51ElSXgEqLIePLJSaOzhCi2ACjQA5fKHko8hW6+Ie+JxIyNuOwvFG+MKT55JXKRkyHWZqOWZ69Fomh5ov83RZZFUXdj3A7qvQg6TlQ2i0IrvvTB7SwHF5DSsev8N8SBZGnEIGl1X9nxTT+cWyDmrBA7LR5fb+ZChsHBhrptXRJsmZRUw0Gx3ldQHxAdtNqHgWgkoe4xMPlr3Di9j6uEOrYWR4GrOJrWL/vikrwNQsQmHdKM7tDxDAdarQhbHWxJkA3GsdCRDFjNn/RpaTMRPnlJPyKCBOmaOCJMk+03vOBf5TPA/wITB7CBYjoRfZ2Xh58ixuNPJNpkuuzbTMpTFZmI2Q3X6MHmnmk/M5ORo/I1oLzEgy4fr73SLw3Gb2j1C9jJ4EJbyVBcpBTlpRiuLL5TT8FFVUkhiWbaQMcJT8CbF+0m4Iu+7TkFZ2sQ4CUS75sPryIyNjzxQzkmXVOVKMjgURc1gmyJFxznKPP/PPjNNccJHJgd5b189o/NyfDcHqW1z28UvaPkIUIouylYnKXP56ds4NUBi7ItWboFBT4qpZnIRZe7V9puj3XwT6O3QOLnDxtUwttnuY1D1PVu6jITA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0684496FAFF843EF4286B0ECF5451DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 525ab8a0-5fc7-408e-ac3b-08d83e144304 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 16:33:21.6786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jbv00AFlwe7ru7o4W4VrW9V0MPqYOVzyzg8AiSSWIaL8mWXytkoLRcnG388oMBb9sCPoiea31PBqNQj6HkI3LQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0555 Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 16:33:28 -0000 --_000_DM6PR00MB0684496FAFF843EF4286B0ECF5451DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG9mIHRoZSB0aGluZ3MgdGhhdCBwZW9wbGUgaGF0ZWQgYWJvdXQgT0F1dGggd2FzIGl0IGlu dmVudGVkIG5ldyB0ZXJtaW5vbG9neSB0aGF0IHdhc27igJl0IGluIGNvbW1vbiB1c2UuICBCdXQg Zm9yIGJldHRlciBvciBmb3Igd29yc2UsIHRoZSB0ZXJtcyBDbGllbnQsIEF1dGhvcml6YXRpb24g U2VydmVyLCBhbmQgUHJvdGVjdGVkIFJlc291cmNlIGFyZSBub3cgd2lkZWx5IHVuZGVyc3Rvb2Qu DQoNCkxldOKAmXMgbm90IG1ha2UgcGVvcGxlIHNpbWlsYXJseSBoYXRlIEdOQVAgYnkgaW52ZW50 aW5nIGV2ZW4gbW9yZSBub3ZlbCB0ZXJtcywgd2hlbiBleGlzdGluZyB0ZXJtcyB3aWxsIGZpdCB0 aGUgYmlsbC4gIENsaWVudCB3YXNu4oCZdCBhIHBlcmZlY3QgY2hvaWNlIGJ1dCBhZGRpbmcg4oCc T3JjaGVzdHJhdG9y4oCdIHRvIHRoZSB2b2NhYnVsYXJ5IG1lbmFnZXJpZSB3b3VsZCBkZWZpbml0 ZWx5IG1ha2UgdGhpbmdzIHdvcnNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUWEF1dGggPHR4YXV0aC1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVG9tIEpvbmVzDQpTZW50OiBUdWVzZGF5LCBB dWd1c3QgMTEsIDIwMjAgODo0NCBBTQ0KVG86IERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9uZXlo dWIuY29tPg0KQ2M6IEZyYW5jaXMgUG91YXRjaGEgPGZwb0BhZG9yc3lzLmRlPjsgSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1PjsgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+ OyBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT47IEZhYmllbiBJbWJhdWx0IDxmYWJpZW4u aW1iYXVsdEBnbWFpbC5jb20+OyBEZW5pcyA8ZGVuaXMuaWV0ZkBmcmVlLmZyPjsgdHhhdXRoQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW0dOQVBdIFRlcm1pbm9sb2d5DQoNCnRoZSB0ZXJtICJvcmNo ZXN0YXRvciIgZG9lcyBub3QgbWF0Y2ggYW55IHVzZSBjYXNlIGkgaGF2ZS4NCkxldCdzIGJlIGNs ZWFyIHRoYXQgdGhlcmUgYXJlIGZvdXIgZW50aXRpZXMgdG8gYSBzaW5nbGUgdHJhbnNhY3Rpb24g aW4gdGhlIHJlYWwgd29ybGQgc2Vuc2Ugb2YgdGhpbmdzLiAoYW5kIG90aGVycyB0aGF0IHN1cHBv cnQgdGhlICB0cmFuc2FjdGlvbi4pDQpUaGVuIHdlIGNhbiBmb2N1cyBvbiB0aGUgZW5kIHBvaW50 IHJvbGVzLiBJIHdpbGwgZm9jdXMgb24gdGhlIGRhdGEgcHJpdmFjeSBpc3N1ZXMsIEFQSSdzIGhh dmUgdGhlIHNhbWUgcGFydGllcyB3aXRoIGRpZmZlcmVudCB0ZXJtaW5vbG9neS4NCjEuIHRoZSBz dWJqZWN0IG9mIHRoZSBkYXRhIHRvIGJlIHRyYW5zZmVycmVkLg0KMi4gdGhlIHVzZXIgb2YgYSBn cmFudCBmcm9tIHRoZSBzdWJqZWN0IHRvIGFjdCBhcyBkZWxlZ2F0ZS4gKHNlZSBodHRwczovL3dp a2kuaWRlc2cub3JnL3dpa2kvaW5kZXgucGhwL0RlbGVnYXRpb24gZm9yIGhvdyB0byBlbmFibGUg dGhlIHVzZXIpDQozLiB0aGUgc2l0ZSB0aGF0IGhhcyBhIHJlcG9zaXRvcnkgb2YgdXNlciBkYXRh IHdpdGggbGVnYWwgb2JsaWdhdGlvbnMgdG8gcHJvdGVjdCB0aGF0IGRhdGEgKHRoZSBHRFBSKSAo cm9sZSByZXNvdXJjZSBzZXJ2ZXIuKQ0KNCB0aGUgc2l0ZSB0aGF0IHdhbnRzIGVpdGhlciBhY2Nl c3MgdG8gdGhlIGRhdGEsIG9yIHNvbWUgcHJpdmFjeSBwcmVzZXJ2aW5nIHN0YXRlbWVudCBhYm91 dCB0aGUgZXhpc3RlbmNlIGFuZCBjb250ZW50IG9mIHRoZSBkYXRhLiAocm9sZSBvZiBjbGllbnQs IHZlbmRvciwgUElTUCwgZXRjLikNCjUuIHNvbWUgc29ydHMgb2YgZmFjaWxpdGF0b3Igc2l0ZXMg Zm9yIGFsbG93aW5nIGFjY2VzcyAocm9sZXMgbGlrZSBhdXRoZW50aWNhdG9yLCBpZHAsIHZlcmlm aWVyLCBjc3AsIFJBLCBldGMgZXRjLiBldGMuICkgdGhlc2UgaGF2ZSBiZWVuIGxlZnQgb3V0IG9m IE9BVVRIIGZvciBnb29kIHJlYXNvbi4NCg0KVGhpcyBpcyBhIG5vdGUgc3VwcG9ydGluZyB0aGUg c2VwYXJhdGlvbiBvZiByb2xlcyBmcm9tIGxlZ2FsIGVudGl0aWVzLiAgQlRXLCBJIGZpcm1seSBi ZWxpZXZlIHRoYXQgdGhlIGxlZ2FsIGVudGl0eSBhbHNvIG5lZWRzIHRvIGJlIElEJ2QgYnkgdGhl IHRyYW5zYWN0aW9uLg0KUGVhY2UgLi50b20NCg0KDQpPbiBUdWUsIEF1ZyAxMSwgMjAyMCBhdCAx OjQyIEFNIERhdmUgVG9uZ2UgPGRhdmUudG9uZ2VAbW9uZXlodWIuY29tPG1haWx0bzpkYXZlLnRv bmdlQG1vbmV5aHViLmNvbT4+IHdyb3RlOg0KSGkgYWxsDQoNCkkgYWdyZWUgdGhhdCAiY2xpZW50 IiBjYW4gYmUgY29uZnVzaW5nLiBJIHdvdWxkIGJlIGluIHN1cHBvcnQgb2YgYWx0ZXJuYXRpdmUg dGVybWlub2xvZ3kuDQpXZSBjYW4gYWx3YXlzIGhhdmUgc29tZSB3b3JkaW5nIHRoYXQgZXhwbGFp bnMgdGhhdCBhbiAiT3JjaGVzdHJhdG9yIiBpbiBHTkFQIHBsYXlzIGEgc2ltaWxhciByb2xlIHRv ICJDbGllbnQiIGluIE9BdXRoLg0KDQpEYXZlDQoNCk9uIFR1ZSwgMTEgQXVnIDIwMjAgYXQgMDc6 NTIsIEZhYmllbiBJbWJhdWx0IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmll bi5pbWJhdWx0QGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgRnJhbmNpcywNCg0KSSBsaWtlIHlvdXIg cHJvcG9zYWwsIHNlZW1zIG11Y2ggbW9yZSBpbnR1aXRpdmUuDQoNCkZhYmllbg0KDQpMZSBtYXIu IDExIGFvw7t0IDIwMjAgw6AgMDQ6MTcsIEZyYW5jaXMgUG91YXRjaGEgPGZwb0BhZG9yc3lzLmRl PG1haWx0bzpmcG9AYWRvcnN5cy5kZT4+IGEgw6ljcml0IDoNCkhlbGxvIERlbmlzLCBKdXN0aW4s IERpY2ssIEZhYmllbiwNCg0KSW4gdGhpcyBwb3N0IChodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3R4YXV0aC9JYVNMQ183Ml9LaW1qT0JKcWRtUVktSk9HTncvKSBpIHN1Z2dl c3RlZCB3ZSB1c2UgdGhlIHdvcmQgIk9yY2hlc3RyYXRvciIgdG8gZGVzaWduYXRlIHRoZSBwaWVj ZSBvZiBzb2Z0d2FyZSB0aGF0IG9yY2hlc3RyYXRlIGludGVyYWN0aW9uIGJldHdlZW4gIlJlcXVl c3RvciIgKGEuay5hLiBVc2VyKSwgQVMgYW5kIFJTIHRvIG9idGFpbiB0aGUgcHJvdGVjdGVkIHJl c291cmNlLg0KDQpXZSBhcmUgdHVybmluZyBhcm91bmQgdGhlIHNhbWUgdG9waWMuIEFzIHNvb24g YXMgd2UgZ28gYmV5b25kIHRoZSBvcmlnaW5hbCBvQXV0aCBwcm90b2NvbCwgdGhlIHdvcmQgJ0Ns aWVudCcgYmVjb21lcyBjb25mdXNpbmcuDQoNCkluIHRoZSBzYW1lIHJlc3BvbnNlLCBJIHN1Z2dl c3Qgd2UgdGFsayBhYm91dCAicm9sZXMiIGFuZCBub3QgImVudGl0aWVzIi4NCg0KQmVzdCByZWdh cmRzLg0KL0ZyYW5jaXMNCg0KT24gVGh1LCBBdWcgNiwgMjAyMCBhdCA2OjM2IFBNIERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdy b3RlOg0KSSBzdGlsbCB0aGluayB0aGF0IGNsaWVudCB3YXMgdGhlIHJpZ2h0IG5hbWUgaW4gT0F1 dGggMiwgYXMgdGhlIGNsaWVudCB3YW50ZWQgdG8gZG8gYSBjbGllbnQtc2VydmVyIGludGVyYWN0 aW9uLCBzbyB0aGUgY2xpZW50IHVzZWQgT0F1dGggMiB0byBnZXQgYW4gYWNjZXNzIHRva2VuIHRv IGludGVyYWN0IHdpdGggdGhlICJzZXJ2ZXIiLg0KDQpJIGRvIGFncmVlIHRoYXQgaXQgaXMgbm90 IHRoZSBiZXN0IHRlcm0gaW4gR05BUC4gUHJpbWFyaWx5IGJlY2F1c2UgR05BUCBpcyBhIGNvbWJp bmF0aW9uIG9mIHRoZSBjbGllbnQgZnJvbSBPQXV0aCAyLCBhbmQgdGhlIHJlbHlpbmcgcGFydHkg ZnJvbSBPSURDLg0KDQovRGljaw0K4ZCnDQoNCk9uIFRodSwgQXVnIDYsIDIwMjAgYXQgMTI6NTAg UE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+ PiB3cm90ZToNCk9uIEF1ZyA2LCAyMDIwLCBhdCAxMjo1MyBQTSwgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNClRo ZSB0ZXJtIGNsaWVudCBpbiBPQXV0aCBjYW1lIGZyb20gdGhlIGNvbXB1dGVyIHNjaWVuY2UgZGVm aW5pdGlvbiBvZiBjbGllbnQtc2VydmVyIGludGVyYWN0aW9uLg0KDQpUaGlzLCBJIHdvdWxkIGFy Z3VlLCBpcyBleGFjdGx5IHdoeSBpdOKAmXMgYSBiYWQgbGFiZWwgZm9yIHNvbWV0aGluZyB0aGF0 4oCZcyBkaXN0aW5jdGx5IG1vcmUgc3BlY2lmaWMgaW4gdGhpcyBjb250ZXh0LCBhbmQgSSB3b3Vs ZCBsb3ZlIHRvIHNlZSBHTkFQIGFkb3B0IGEgbW9yZSBzcGVjaWZpYyBsYWJlbCBmb3IgdGhlIHJv bGUgdGhhdCB3ZSB0cmFkaXRpb25hbGx5IGNhbGxlZCDigJxjbGllbnTigJ0gaW4gT0F1dGguDQoN CiDigJQgSnVzdGluDQoNCg0KDQpUaGUgY2xpZW50IGlzIGdldHRpbmcgYW4gYWNjZXNzIHRva2Vu IHNvIGl0IGNhbiBjYWxsIGEgc2VydmVyLCBzcGVjaWZpY2FsbHksIGEgcmVzb3VyY2Ugc2VydmVy ICh0byBkaWZmZXJlbnRpYXRlIGl0IGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyKS4NCg0K VGhlIGNvbmZ1c2lvbiBpbiBteSBleHBlcmllbmNlIHVzdWFsbHkgc3RlbXMgZnJvbSBwZW9wbGUg d29ya2luZyB3aXRoIHNvZnR3YXJlIHRoYXQgaXMgYWN0aW5nIGluIG11bHRpcGxlIHJvbGVzLiBJ RSwgdGhlIHNvZnR3YXJlIHRoYXQgaXMgYWN0aW5nIGFzIGEgY2xpZW50IGluIG9uY2UgY29udGV4 dCwgaXMgYWxzbyBhY3RpbmcgYXMgYW4gUlMgaW4gb3RoZXIgY29udGV4dHMsIG9yIGV2ZW4gYWN0 aW5nIGFzIGFuIEFTLiBUaGUgb3RoZXIgY29uZnVzaW9uIGlzIHRoYXQgcGVvcGxlIHZpZXcgY2xp ZW50cyBhcyBiZWluZyB0aGUgc29mdHdhcmUgdGhlIHVzZXIgaXMgdXNpbmcgLS0gYWx0aG91Z2gg aXQgbWF5IG5vdCBiZSBhY3RpbmcgYXMgYSBjbGllbnQgaW4gdGhlIG9hdXRoIGNvbnRleHQuDQoN Cg0KDQrhkKcNCg0KT24gVGh1LCBBdWcgNiwgMjAyMCBhdCA0OjQ5IEFNIEZhYmllbiBJbWJhdWx0 IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNv bT4+IHdyb3RlOg0KSGksDQoNClRvIG1lLCBjbGllbnQgaGFzIGFsd2F5cyBiZWVuIGEgc3RyYW5n ZSB3b3JkIGluIHRoZSBjb250ZXh0IG9mIE9BdXRoLCBhcyBpdCBoYXMgYSBtZWFuaW5nIHdlbGwg ZGVmaW5lZCBib3RoIGluIGV2ZXJ5ZGF5IGxpZmUgKHRoaXMgY2xpZW50IGlzIGEgZ29vZCBjdXN0 b21lcikgYW5kIGluIGNvbXB1dGVyIHNjaWVuY2UgKGNsaWVudC1zZXJ2ZXIgaW50ZXJhY3Rpb24p LiBUaHVzIEkgYWx3YXlzIGhhdmUgdG8gbWFrZSB0aGUgbWVudGFsIHRyYW5zbGF0aW9uIHRvIHRo ZSBPQXV0aCB3b3JsZCBiZWZvcmUgYW55IGRpc2N1c3Npb24uLi4gQW5kIGFueSB0ZWFjaGluZyBl eHBlcmllbmNlIHNob3dzIHRoYXQgaXQgZG9lcyBtYWtlIHRoZSBjb25jZXB0cyBoYXJkIHRvIGdy YXNwIGZvciBhIG1ham9yaXR5IG9mIChjbGV2ZXIpIHBlb3BsZS4NCg0KQXMgZm9yIHRoZSBSTywg cHJldmlvdXMgZGlzY3Vzc2lvbnMgc3VnZ2VzdGVkIFJlc291cmNlIENvbnRyb2xsZXIgKFJDKSBh bHNvLCB3aGljaCBtYXkgYmUgYSBiaXQgbW9yZSBzcGVjaWZpYyB0aGFuIG1hbmFnZXIuDQoNCkZh Ymllbg0KDQpPbiBUaHUsIEF1ZyA2LCAyMDIwIGF0IDE6MDAgUE0gRGVuaXMgPGRlbmlzLmlldGZA ZnJlZS5mcjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyPj4gd3JvdGU6DQpKdXN0aW4gYW5kIERp Y2ssDQoNCltXYXM6ICAiUmV2aXNpdGluZyB0aGUgcGhvdG8gc2hhcmluZyBleGFtcGxlIChhIGRy aXZpbmcgdXNlIGNhc2UgZm9yIHRoZSBjcmVhdGlvbiBvZiBPQXV0aCkiXQ0KDQpTbyBsZXQgdXMg YXR0ZW1wdCB0byBkZWZpbmUgbmV3IHRlcm1zOg0KaW5pdGlhdGluZyBhcHBsaWNhdGlvbiAoSUEp OiBhcHBsaWNhdGlvbiBieSBtZWFucyBvZiB3aGljaCBhIHVzZXIgaW5pdGlhdGVzIGludGVyYWN0 aW9ucyB3aXRoIFJTKHMpIGFuZCBBUyhzKQ0KSW4gdGhlIHNhbWUgd2F5LCB3ZSBzaG91bGQgZ2V0 IHJpZCBvZiB0aGUgdGVybSBSZXNvdXJjZSBPd25lciAoUk8pLCB3aGljaCBpcyBjdXJyZW50bHkg ZGVmaW5lZCBhczoNClJlc291cmNlIE93bmVyIChSTyk6IGVudGl0eSBjYXBhYmxlIG9mIGdyYW50 aW5nIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZQ0KSSBwcm9wb3NlIHRvIHJlcGxhY2Ug aXQgd2l0aCBSZXNvdXJjZSBNYW5hZ2VyIChSTSk6DQpSZXNvdXJjZSBNYW5hZ2VyIChSTSkgOiBh cHBsaWNhdGlvbiBvciB1c2VyIHRoYXQgbWFuYWdlcyBhbiBhY2Nlc3MgZGVjaXNpb24gZnVuY3Rp b24gb2YgYSBSZXNvdXJjZSBTZXJ2ZXINCkRlbmlzDQoNCkkgYWdyZWUgd2l0aCBKdXN0aW4uIFJl ZGVmaW5pbmcgd2VsbCB1c2VkIHRlcm1zIHdpbGwgbGVhZCB0byBzaWduaWZpY2FudCBjb25mdXNp b24uIElmIHdlIGhhdmUgYSBkaWZmZXJlbnQgcm9sZSB0aGFuIHdoYXQgd2UgaGF2ZSBoYWQgaW4g dGhlIHBhc3QsIHRoZW4gdGhhdCByb2xlIHNob3VsZCBoYXZlIGEgbmFtZSBub3QgYmVpbmcgdXNl ZCBhbHJlYWR5IGluIE9BdXRoIG9yIE9JREMuDQoNCkdpdmVuIHdoYXQgd2UgaGF2ZSBsZWFybmVk LCBhbmQgbXkgb3duIGV4cGVyaWVuY2UgZXhwbGFpbmluZyB3aGF0IGEgQ2xpZW50IGlzLCBhbmQg aXMgbm90LCBpbXByb3ZpbmcgdGhlIGRlZmluaXRpb24gZm9yIENsaWVudCBjb3VsZCBwcm92ZSB1 c2VmdWwuIEkgYW0gbm90IHN1Z2dlc3RpbmcgdGhlIHRlcm0gYmUgcmVkZWZpbmVkLCBidXQgY2xh cmlmaWVkLg0KDQpGb3IgZXhhbXBsZSwgY2xhcmlmeWluZyB0aGF0IGEgQ2xpZW50IGlzIGEgcm9s ZSBhbiBlbnRpdHkgcGxheXMgaW4gdGhlIHByb3RvY29sLCBhbmQgdGhhdCB0aGUgc2FtZSBlbnRp dHkgbWF5IHBsYXkgb3RoZXIgcm9sZXMgYXQgb3RoZXIgdGltZXMsIG9yIHNvbWUgb3RoZXIgbGFu Z3VhZ2UgdG8gaGVscCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gInJvbGUiIGFuZCAiZW50aXR5Ii4N Cg0KL0RpY2sNCuGQpw0KDQpPbiBXZWQsIEF1ZyA1LCAyMDIwIGF0IDg6MjAgQU0gSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkni gJltIGluIGZhdm9yIG9mIGNvbWluZyB1cCB3aXRoIGEgbmV3IHRlcm0gdGhhdOKAmXMgYSBiZXR0 ZXIgZml0LCBidXQgSeKAmW0gbm90IHJlYWxseSBpbiBmYXZvciBvZiB0YWtpbmcgYW4gZXhpc3Rp bmcgdGVybSBhbmQgYXBwbHlpbmcgYSBjb21wbGV0ZWx5IG5ldyBkZWZpbml0aW9uIHRvIGl0LiBJ biBvdGhlciB3b3JkcywgSSB3b3VsZCBzb29uZXIgc3RvcCB1c2luZyDigJxjbGllbnTigJ0gYW5k IGNvbWUgdXAgd2l0aCBhIG5ldywgbW9yZSBzcGVjaWZpYyBhbmQgYWNjdXJhdGUgdGVybSBmb3Ig dGhlIHJvbGUgdGhhbiB0byBkZWZpbmUg4oCcY2xpZW504oCdIGFzIG1lYW5pbmcgc29tZXRoaW5n IGNvbXBsZXRlbHkgZGlmZmVyZW50LiBXZSBkaWQgdGhpcyBpbiBnb2luZyBmcm9tIE9BdXRoIDEg dG8gT0F1dGggMiBhbHJlYWR5LCBtb3ZpbmcgZnJvbSB0aGUgZXZlbi1tb3JlLWNvbmZ1c2luZyDi gJxjb25zdW1lcuKAnSB0byDigJxjbGllbnTigJ0sIGJ1dCBPQXV0aCAyIGRvZXNu4oCZdCB1c2Ug dGhlIHRlcm0g4oCcY29uc3VtZXLigJ0gYXQgYWxsLCBub3IgZG9lcyBpdCB1c2Ug4oCcc2VydmVy 4oCdIG9uIGl0cyBvd24gYnV0IGluc3RlYWQgYWx3YXlzIHF1YWxpZmllcyBpdCB3aXRoIOKAnEF1 dGhvcml6YXRpb24gU2VydmVy4oCdIGFuZCDigJxSZXNvdXJjZSBTZXJ2ZXLigJ0uDQoNCkdOQVAg Y2FuIGRvIHNvbWV0aGluZyBzaW1pbGFyLCBpbiBteSBvcGluaW9uLiBCdXQgd2hhdCB3ZSBjYW7i gJl0IGRvIGlzIGlnbm9yZSB0aGUgZmFjdCB0aGF0IEdOQVAgaXMgZ29pbmcgdG8gYmUgY29taW5n IHVwIGluIGEgd29ybGQgdGhhdCBpcyBhbHJlYWR5IHBlcm1lYXRlZCAgYnkgT0F1dGggMiBhbmQg aXRzIHRlcm1pbm9sb2d5LiBXZSBkb27igJl0IGhhdmUgYSBibGFuayBzbGF0ZSB0byB3b3JrIHdp dGgsIGJ1dCBuZWl0aGVyIGFyZSB3ZSBib3VuZCB0byB1c2UgdGhlIHNhbWUgdGVybXMgYW5kIGNv bnN0cnVjdHMgYXMgYmVmb3JlLiBJdOKAmXMgZ29pbmcgdG8gYmUgYSBkZWxpY2F0ZSBiYWxhbmNl IQ0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEF1ZyA0LCAyMDIwLCBhdCAzOjMyIFBNLCBXYXJyZW4g UGFyYWQgPHdwYXJhZEByaG9zeXMuY2g8bWFpbHRvOndwYXJhZEByaG9zeXMuY2g+PiB3cm90ZToN Cg0KSSB0aGluayB0aGF0IGlzIGZ1bmRhbWVudGFsbHkgcGFydCBvZiB0aGUgcXVlc3Rpb246DQpX ZSBhcmUgY2xlYXIgdGhhdCB3ZSBhcmUgcHJvZHVjaW5nIGEgcHJvdG9jb2wgdGhhdCBpcw0KY29u Y2VwdHVhbGx5IChpZiBub3QgbW9yZSBzdHJvbmdseSkgcmVsYXRlZCB0byBPQXV0aCAyLjAsIGFu ZCByZXVzaW5nIHRlcm1zDQpmcm9tIE9BdXRoIDIuMCBidXQgd2l0aCBkaWZmZXJlbnQgZGVmaW5p dGlvbnMgbWF5IGxlYWQgdG8gdW5uZWNlc3NhcnkNCmNvbmZ1c2lvbg0KDQpJZiB3ZSBzYXkgdGhh dCB0aGlzIGRvY3VtZW50IGFzc3VtZXMgT0F1dGgyLjAgdGVybWlub2xvZ3ksIHRoZW4gd2Ugc2hv dWxkIG5vdCBjaGFuZ2UgdGhlIG1lYW5pbmdzIG9mIGFueSBkZWZpbml0aW9uLiBJZiB3ZSBhcmUg c2F5aW5nIHRoaXMgc3VwZXJzZWRlcyBvciByZXBsYWNlcyB3aGF0IE9BdXRoIDIuMCBjcmVhdGVz LCB0aGVuIHdlIHNob3VsZCBwaWNrIHRoZSBiZXN0IHdvcmQgZm9yIHRoZSBqb2IgYW5kIGlnbm9y ZSBjb25mbGljdGluZyBtZWFuaW5ncyBmcm9tIE9BdXRoIDIuMC4gSSBoYXZlIGEgbG90IG9mIGZp cnN0IGhhbmQgZXhwZXJpZW5jZSBvZiBpbmR1c3RyaWVzICJydWluaW5nIHdvcmRzIiwgYW5kIGF0 dGVtcHRpbmcgdG8gc2lkZS1zdGVwIHRoZSBwcm9ibGVtIHJhdGhlciB0aGFuIHJlZGVmaW5pbmcg dGhlIHdvcmQganVzdCBjb25mdXNlcyBldmVyeW9uZSBhcyBldmVyeW9uZSBmb3JnZXRzIHRoZSBv cmlnaW5hbCBtZWFuaW5nIGFzIG5ldyBkb2N1bWVudHMgY29tZSBvdXQsIGJ1dCB0aGUgY29uZnVz aW9uIHdpdGggdGhlIHVzZSBvZiBhIG5vbi1vYnZpb3VzIHdvcmQgY29udGludWVzLg0KDQpGb29k IGZvciB0aG91Z2h0Lg0KLSBXYXJyZW4NCg0KW2h0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50 LmNvbS9ETmlEeDFRR0lyU3FNUEtETjFvS2V2eFl1eVZSWHNxaFhkZlpPc1c1NlJmMkE3NG1VS2JB UHRySlNOdzRxeW5rU2pvbHRXa1BZZEJoYVpKZzFCTzQ1WU9jMXhzNnI5S0oxZllzTkhvZ1ktbmg2 aGp1SW05R0NlQlJSenJTYzhrV2NVU050dUFdDQpXYXJyZW4gUGFyYWQNCkZvdW5kZXIsIENUTw0K U2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJj aGl0ZWN0dXJlLiBJbXBsZW1lbnQgQXV0aHJlc3M8aHR0cHM6Ly9iaXQubHkvMzdTU08xcD4uDQoN Cg0KT24gVHVlLCBBdWcgNCwgMjAyMCBhdCA4OjUzIFBNIEJlbmphbWluIEthZHVrIDxrYWR1a0Bt aXQuZWR1PG1haWx0bzprYWR1a0BtaXQuZWR1Pj4gd3JvdGU6DQpIaSBEZW5pcywNCg0KT24gVHVl LCBBdWcgMDQsIDIwMjAgYXQgMTE6MzE6MzRBTSArMDIwMCwgRGVuaXMgd3JvdGU6DQo+IEhpIEp1 c3RpbiwNCj4NCj4gU2luY2UgeW91IHJlcGxpZWQgaW4gcGFyYWxsZWwsIEkgd2lsbCBtYWtlIGEg cmVzcG9uc2Ugc2ltaWxhciB0byB0aGUgb25lDQo+IEkgc2VudCB0byBEaWNrLg0KPg0KPiA+IEhp IERlbmlzLA0KPiA+DQo+ID4gSSB0aGluayB0aGVyZeKAmXMgc3RpbGwgYSBwcm9ibGVtIHdpdGgg dGhlIHRlcm1pbm9sb2d5IGluIHVzZSBoZXJlLiBXaGF0DQo+ID4geW91IGRlc2NyaWJlIGFzIFJT Miwgd2hpY2ggbWlnaHQgaW4gZmFjdCBiZSBhbiBSUyB1bnRvIGl0c2VsZiwgaXMgYQ0KPiA+IOKA nENsaWVudOKAnSBpbiBPQXV0aCBwYXJsYW5jZSBiZWNhdXNlIGl0IGlzIC9hIGNsaWVudCBvZiBS UzEvLiBXaGF0IHlvdQ0KPiA+IGNhbGwgYSDigJxjbGllbnTigJ0gaGFzIG5vIGFuYWxvZ3VlIGlu IHRoZSBPQXV0aCB3b3JsZCwgYnV0IGl0IGlzIG5vdCBhdA0KPiA+IGFsbCB0aGUgc2FtZSBhcyBh biBPQXV0aCBjbGllbnQuIEkgYXBwcmVjaWF0ZSB5b3VyIG1hcHBpbmcgb2YgdGhlDQo+ID4gZW50 aXRpZXMgYmVsb3csIGJ1dCBpdCBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gaG9sZCBhIGRpc2N1c3Np b24gaWYgd2UNCj4gPiBhcmVu4oCZdCB1c2luZyB0aGUgc2FtZSB0ZXJtcy4NCj4gPg0KPiA+IFRo ZSBnb29kIG5ld3MgaXMgdGhhdCB0aGlzIGlzbuKAmXQgT0F1dGgsIGFuZCBhcyBhIG5ldyBXRyB3 ZSBjYW4gZGVmaW5lDQo+ID4gb3VyIG93biB0ZXJtcy4gVGhlIGJhZCBuZXdzIGlzIHRoYXQgdGhp cyBpcyByZWFsbHkgaGFyZCB0byBkby4NCj4gPg0KPiA+IEluIEdOQVAsIHdlIHNob3VsZG7igJl0 IGp1c3QgcmUtdXNlIGV4aXN0aW5nIHRlcm1zIHdpdGggbmV3IGRlZmluaXRpb25zLA0KPiA+IGJ1 dCB3ZeKAmXZlIGdvdCBhIGNoYW5jZSB0byBiZSBtb3JlIHByZWNpc2Ugd2l0aCBob3cgd2UgZGVm aW5lIHRoaW5ncy4NCj4NCj4gSW4gdGhlIElTTyBjb250ZXh0LCBlYWNoIGRvY3VtZW50IG11c3Qg ZGVmaW5lIGl0cyBvd24gdGVybWlub2xvZ3kuIFRoZQ0KPiBib2lsZXIgcGxhdGUgZm9yIFJGQ3Mg ZG9lcyBub3QgbWFuZGF0ZSBhIHRlcm1pbm9sb2d5IG9yIGRlZmluaXRpb25zIHNlY3Rpb24NCj4g YnV0IGRvZXMgbm90IHByZXZlbnQgaXQgZWl0aGVyLiBUaGUgdm9jYWJ1bGFyeSBpcyBsaW1pdGVk IGFuZCBhcyBsb25nIGFzDQo+IHdlIGNsZWFybHkgZGVmaW5lIHdoYXQgb3VyIHRlcm1zIGFyZSBt ZWFuaW5nLCB3ZSBjYW4gcmUtdXNlIGEgdGVybSBhbHJlYWR5DQo+IHVzZWQgaW4gYW5vdGhlciBS RkMuIFRoaXMgaXMgYWxzbyB0aGUgSVNPIGFwcHJvYWNoLg0KDQpKdXN0IGJlY2F1c2Ugd2UgY2Fu IGRvIHNvbWV0aGluZyBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgaXQgaXMgYQ0KZ29v ZCBpZGVhIHRvIGRvIHNvLiAgV2UgYXJlIGNsZWFyIHRoYXQgd2UgYXJlIHByb2R1Y2luZyBhIHBy b3RvY29sIHRoYXQgaXMNCmNvbmNlcHR1YWxseSAoaWYgbm90IG1vcmUgc3Ryb25nbHkpIHJlbGF0 ZWQgdG8gT0F1dGggMi4wLCBhbmQgcmV1c2luZyB0ZXJtcw0KZnJvbSBPQXV0aCAyLjAgYnV0IHdp dGggZGlmZmVyZW50IGRlZmluaXRpb25zIG1heSBsZWFkIHRvIHVubmVjZXNzYXJ5DQpjb25mdXNp b24uICBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBhIHNpbWlsYXIgcmVhc29uaW5nIHByb21w dGVkIERpY2sgdG8NCnVzZSB0aGUgdGVybSAiR1MiIGluIFhBdXRoLCBwaWNraW5nIGEgbmFtZSB0 aGF0IHdhcyBub3QgYWxyZWFkeSB1c2VkIGluDQpPQXV0aCAyLjAuDQoNCi1CZW4NCg0KLS0NClR4 YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCi0tDQpUeGF1 dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCi0tDQpUWEF1 dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg0KLS0NClRY QXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KLS0NClRY QXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KDQotLQ0K RnJhbmNpcyBQb3VhdGNoYQ0KQ28tRm91bmRlciBhbmQgVGVjaG5pY2FsIExlYWQNCmFkb3JzeXMg R21iSCAmIENvLiBLRw0KaHR0cHM6Ly9hZG9yc3lzLXBsYXRmb3JtLmRlL3NvbHV0aW9ucy8NCi0t DQpUWEF1dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg0K DQpNb25leWh1YiBFbnRlcnByaXNlIGlzIGEgdHJhZGluZyBzdHlsZSBvZiBNb25leWh1YiBGaW5h bmNpYWwgVGVjaG5vbG9neSBMaW1pdGVkIHdoaWNoIGlzIGF1dGhvcmlzZWQgYW5kIHJlZ3VsYXRl ZCBieSB0aGUgRmluYW5jaWFsIENvbmR1Y3QgQXV0aG9yaXR5ICgiRkNBIikuIE1vbmV5aHViIEZp bmFuY2lhbCBUZWNobm9sb2d5IGlzIGVudGVyZWQgb24gdGhlIEZpbmFuY2lhbCBTZXJ2aWNlcyBS ZWdpc3RlciAoRlJOIDgwOTM2MCkgYXQgaHR0cHM6Ly9yZWdpc3Rlci5mY2Eub3JnLnVrLy4gTW9u ZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgaXMgcmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMsIGNvbXBhbnkgcmVnaXN0cmF0aW9uIG51bWJlciAwNjkwOTc3Mi4gTW9uZXlodWIgRmluYW5j aWFsIFRlY2hub2xvZ3kgTGltaXRlZCAyMDIwIMKpIE1vbmV5aHViIEVudGVycHJpc2UsIFJlZ3Vz IEJ1aWxkaW5nLCBUZW1wbGUgUXVheSwgMSBGcmlhcnksIEJyaXN0b2wsIEJTMSA2RUEuDQoNCkRJ U0NMQUlNRVI6IFRoaXMgZW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIHN1Ympl Y3QgdG8gY29weXJpZ2h0LCBhbmQgdGhlIGluZm9ybWF0aW9uIGluIGl0IGlzIGNvbmZpZGVudGlh bC4gVXNlIG9mIHRoaXMgZW1haWwgb3Igb2YgYW55IGluZm9ybWF0aW9uIGluIGl0IG90aGVyIHRo YW4gYnkgdGhlIGFkZHJlc3NlZSBpcyB1bmF1dGhvcmlzZWQgYW5kIHVubGF3ZnVsLiBXaGlsc3Qg cmVhc29uYWJsZSBlZmZvcnRzIGFyZSBtYWRlIHRvIGVuc3VyZSB0aGF0IGFueSBhdHRhY2htZW50 cyBhcmUgdmlydXMtZnJlZSwgaXQgaXMgdGhlIHJlY2lwaWVudCdzIHNvbGUgcmVzcG9uc2liaWxp dHkgdG8gc2NhbiBhbGwgYXR0YWNobWVudHMgZm9yIHZpcnVzZXMuIEFsbCBjYWxscyBhbmQgZW1h aWxzIHRvIGFuZCBmcm9tIHRoaXMgY29tcGFueSBtYXkgYmUgbW9uaXRvcmVkIGFuZCByZWNvcmRl ZCBmb3IgbGVnaXRpbWF0ZSBwdXJwb3NlcyByZWxhdGluZyB0byB0aGlzIGNvbXBhbnkncyBidXNp bmVzcy4gQW55IG9waW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIGVtYWlsIChvciBpbiBhbnkgYXR0 YWNobWVudHMpIGFyZSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkg cmVwcmVzZW50IHRoZSBvcGluaW9ucyBvZiBNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBM aW1pdGVkIG9yIG9mIGFueSBvdGhlciBncm91cCBjb21wYW55Lg0KDQotLQ0KVFhBdXRoIG1haWxp bmcgbGlzdA0KVFhBdXRoQGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0K --_000_DM6PR00MB0684496FAFF843EF4286B0ECF5451DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlRyZWJ1Y2hldCBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDMgMiAyIDIgMiAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk9uZSBv ZiB0aGUgdGhpbmdzIHRoYXQgcGVvcGxlIGhhdGVkIGFib3V0IE9BdXRoIHdhcyBpdCBpbnZlbnRl ZCBuZXcgdGVybWlub2xvZ3kgdGhhdCB3YXNu4oCZdCBpbiBjb21tb24gdXNlLiZuYnNwOyBCdXQg Zm9yIGJldHRlciBvciBmb3Igd29yc2UsIHRoZSB0ZXJtcyBDbGllbnQsIEF1dGhvcml6YXRpb24g U2VydmVyLCBhbmQgUHJvdGVjdGVkIFJlc291cmNlIGFyZSBub3cNCiB3aWRlbHkgdW5kZXJzdG9v ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkxldOKAmXMgbm90IG1ha2Ug cGVvcGxlIHNpbWlsYXJseSBoYXRlIEdOQVAgYnkgaW52ZW50aW5nIGV2ZW4gbW9yZSBub3ZlbCB0 ZXJtcywgd2hlbiBleGlzdGluZyB0ZXJtcyB3aWxsIGZpdCB0aGUgYmlsbC4mbmJzcDsgQ2xpZW50 IHdhc27igJl0IGEgcGVyZmVjdCBjaG9pY2UgYnV0IGFkZGluZyDigJxPcmNoZXN0cmF0b3LigJ0g dG8gdGhlIHZvY2FidWxhcnkgbWVuYWdlcmllIHdvdWxkDQogZGVmaW5pdGVseSBtYWtlIHRoaW5n cyB3b3JzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVFhBdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9y ZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+VG9tIEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEF1Z3VzdCAxMSwgMjAyMCA4OjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBEYXZlIFRvbmdl ICZsdDtkYXZlLnRvbmdlQG1vbmV5aHViLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEZyYW5jaXMg UG91YXRjaGEgJmx0O2Zwb0BhZG9yc3lzLmRlJmd0OzsgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hl ckBtaXQuZWR1Jmd0OzsgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7OyBC ZW5qYW1pbiBLYWR1ayAmbHQ7a2FkdWtAbWl0LmVkdSZndDs7IEZhYmllbiBJbWJhdWx0ICZsdDtm YWJpZW4uaW1iYXVsdEBnbWFpbC5jb20mZ3Q7OyBEZW5pcyAmbHQ7ZGVuaXMuaWV0ZkBmcmVlLmZy Jmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbR05BUF0gVGVy bWlub2xvZ3k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRo ZSB0ZXJtICZxdW90O29yY2hlc3RhdG9yJnF1b3Q7IGRvZXMgbm90IG1hdGNoIGFueSB1c2UgY2Fz ZSBpIGhhdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5MZXQncyBiZSBjbGVhciB0aGF0IHRoZXJlIGFyZSBmb3VyIGVudGl0aWVzIHRvIGEgc2lu Z2xlIHRyYW5zYWN0aW9uIGluIHRoZSByZWFsIHdvcmxkIHNlbnNlIG9mIHRoaW5ncy4gKGFuZCBv dGhlcnMgdGhhdCBzdXBwb3J0IHRoZSZuYnNwOyB0cmFuc2FjdGlvbi4pPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuIHdlIGNhbiBmb2N1cyBv biB0aGUgZW5kIHBvaW50IHJvbGVzLiBJIHdpbGwgZm9jdXMgb24gdGhlIGRhdGEgcHJpdmFjeSBp c3N1ZXMsIEFQSSdzIGhhdmUgdGhlIHNhbWUgcGFydGllcyB3aXRoIGRpZmZlcmVudCB0ZXJtaW5v bG9neS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjEuIHRoZSBzdWJqZWN0IG9mIHRoZSBkYXRhIHRvIGJlIHRyYW5zZmVycmVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gdGhlIHVzZXIgb2Yg YSBncmFudCBmcm9tIHRoZSBzdWJqZWN0IHRvIGFjdCBhcyBkZWxlZ2F0ZS4gKHNlZQ0KPGEgaHJl Zj0iaHR0cHM6Ly93aWtpLmlkZXNnLm9yZy93aWtpL2luZGV4LnBocC9EZWxlZ2F0aW9uIj5odHRw czovL3dpa2kuaWRlc2cub3JnL3dpa2kvaW5kZXgucGhwL0RlbGVnYXRpb248L2E+IGZvciBob3cg dG8gZW5hYmxlIHRoZSB1c2VyKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+My4gdGhlIHNpdGUgdGhhdCBoYXMgYSByZXBvc2l0b3J5IG9mIHVzZXIg ZGF0YSB3aXRoIGxlZ2FsIG9ibGlnYXRpb25zIHRvIHByb3RlY3QgdGhhdCBkYXRhICh0aGUgR0RQ UikgKHJvbGUgcmVzb3VyY2Ugc2VydmVyLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQgdGhlIHNpdGUgdGhhdCB3YW50cyBlaXRoZXIgYWNjZXNz IHRvIHRoZSBkYXRhLCBvciBzb21lIHByaXZhY3kgcHJlc2VydmluZyBzdGF0ZW1lbnQgYWJvdXQg dGhlIGV4aXN0ZW5jZSBhbmQgY29udGVudCBvZiB0aGUgZGF0YS4gKHJvbGUgb2YgY2xpZW50LCB2 ZW5kb3IsIFBJU1AsIGV0Yy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj41LiBzb21lIHNvcnRzIG9mIGZhY2lsaXRhdG9yIHNpdGVzIGZvciBhbGxv d2luZyBhY2Nlc3MgKHJvbGVzIGxpa2UgYXV0aGVudGljYXRvciwgaWRwLCB2ZXJpZmllciwgY3Nw LCBSQSwgZXRjIGV0Yy4gZXRjLiApIHRoZXNlIGhhdmUgYmVlbiBsZWZ0IG91dCBvZiBPQVVUSCBm b3IgZ29vZCByZWFzb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBub3RlIHN1cHBvcnRpbmcgdGhlIHNlcGFyYXRpb24gb2Yg cm9sZXMgZnJvbSBsZWdhbCBlbnRpdGllcy4mbmJzcDsgQlRXLCBJIGZpcm1seSBiZWxpZXZlIHRo YXQgdGhlIGxlZ2FsIGVudGl0eSBhbHNvIG5lZWRzIHRvIGJlIElEJ2QgYnkgdGhlIHRyYW5zYWN0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZWFjZSAuLnRvbTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAxMSwgMjAyMCBhdCAxOjQyIEFNIERhdmUgVG9uZ2Ug Jmx0OzxhIGhyZWY9Im1haWx0bzpkYXZlLnRvbmdlQG1vbmV5aHViLmNvbSI+ZGF2ZS50b25nZUBt b25leWh1Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+SGkg YWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgdGhhdCAmcXVvdDtjbGllbnQmcXVvdDsg Y2FuIGJlIGNvbmZ1c2luZy4gSSB3b3VsZCBiZSBpbiBzdXBwb3J0IG9mIGFsdGVybmF0aXZlIHRl cm1pbm9sb2d5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMm cXVvdDssc2Fucy1zZXJpZiI+V2UgY2FuIGFsd2F5cyBoYXZlIHNvbWUgd29yZGluZyB0aGF0IGV4 cGxhaW5zIHRoYXQgYW4gJnF1b3Q7T3JjaGVzdHJhdG9yJnF1b3Q7IGluIEdOQVAgcGxheXMgYSBz aW1pbGFyIHJvbGUgdG8gJnF1b3Q7Q2xpZW50JnF1b3Q7IGluIE9BdXRoLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5z LXNlcmlmIj5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIDExIEF1ZyAyMDIwIGF0IDA3OjUyLCBGYWJpZW4gSW1i YXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBGcmFuY2lzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBsaWtlIHlvdXIgcHJvcG9zYWwsIHNlZW1zIG11Y2ggbW9yZSBpbnR1aXRpdmUu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZhYmllbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5MZSBtYXIuIDExIGFvw7t0IDIwMjAgw6AgMDQ6MTcsIEZyYW5jaXMgUG91 YXRjaGEgJmx0OzxhIGhyZWY9Im1haWx0bzpmcG9AYWRvcnN5cy5kZSIgdGFyZ2V0PSJfYmxhbmsi PmZwb0BhZG9yc3lzLmRlPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gRGVu aXMsIEp1c3RpbiwgRGljaywgRmFiaWVuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBwb3N0ICg8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC9JYVNMQ183Ml9LaW1qT0JKcWRtUVktSk9HTncvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90eGF1 dGgvSWFTTENfNzJfS2ltak9CSnFkbVFZLUpPR053LzwvYT4pIGkgc3VnZ2VzdGVkIHdlIHVzZSB0 aGUgd29yZCAmcXVvdDtPcmNoZXN0cmF0b3ImcXVvdDsNCiB0byBkZXNpZ25hdGUgdGhlIHBpZWNl IG9mIHNvZnR3YXJlIHRoYXQgb3JjaGVzdHJhdGUgaW50ZXJhY3Rpb24gYmV0d2VlbiAmcXVvdDtS ZXF1ZXN0b3ImcXVvdDsgKGEuay5hLiBVc2VyKSwgQVMgYW5kIFJTIHRvIG9idGFpbiB0aGUgcHJv dGVjdGVkIHJlc291cmNlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgdHVybmluZyBhcm91bmQgdGhlIHNhbWUgdG9waWMu IEFzIHNvb24gYXMgd2UgZ28gYmV5b25kJm5ic3A7dGhlIG9yaWdpbmFsIG9BdXRoIHByb3RvY29s LCB0aGUgd29yZCAnQ2xpZW50JyBiZWNvbWVzIGNvbmZ1c2luZy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIHNhbWUgcmVzcG9uc2Us IEkgc3VnZ2VzdCZuYnNwO3dlIHRhbGsgYWJvdXQgJnF1b3Q7cm9sZXMmcXVvdDsgYW5kIG5vdCAm cXVvdDtlbnRpdGllcyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L0ZyYW5jaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgNiwgMjAyMCBhdCA2 OjM2IFBNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBzdGlsbCB0aGluayB0aGF0IGNsaWVudCB3YXMgdGhlIHJpZ2h0IG5hbWUgaW4gT0F1 dGggMiwgYXMgdGhlIGNsaWVudCB3YW50ZWQgdG8gZG8gYSBjbGllbnQtc2VydmVyIGludGVyYWN0 aW9uLCBzbyB0aGUgY2xpZW50IHVzZWQgT0F1dGggMiB0byBnZXQgYW4gYWNjZXNzIHRva2VuIHRv IGludGVyYWN0IHdpdGggdGhlICZxdW90O3NlcnZlciZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gYWdyZWUgdGhhdCBpdCBpcyBub3QgdGhl IGJlc3QgdGVybSBpbiBHTkFQLiBQcmltYXJpbHkgYmVjYXVzZSBHTkFQIGlzIGEgY29tYmluYXRp b24gb2YgdGhlIGNsaWVudCBmcm9tIE9BdXRoIDIsIGFuZCB0aGUgcmVseWluZyBwYXJ0eSBmcm9t IE9JREMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBz dHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyOCIgc3Jj PSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD02MmFiZGMxZS1k ZWU0LTQwNDMtOWNkOS0yYTcxMjgwY2JjZTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQ pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFRodSwgQXVnIDYsIDIwMjAgYXQgMTI6NTAgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyA2LCAyMDIwLCBhdCAxMjo1MyBQTSwgRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGVybSBjbGllbnQgaW4gT0F1dGgg Y2FtZSBmcm9tIHRoZSBjb21wdXRlciBzY2llbmNlIGRlZmluaXRpb24gb2YgY2xpZW50LXNlcnZl ciBpbnRlcmFjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzLCBJIHdvdWxkIGFyZ3VlLCBp cyBleGFjdGx5IHdoeSBpdOKAmXMgYSBiYWQgbGFiZWwgZm9yIHNvbWV0aGluZyB0aGF04oCZcyBk aXN0aW5jdGx5IG1vcmUgc3BlY2lmaWMgaW4gdGhpcyBjb250ZXh0LCBhbmQgSSB3b3VsZCBsb3Zl IHRvIHNlZSBHTkFQIGFkb3B0IGEgbW9yZSBzcGVjaWZpYyBsYWJlbCBmb3IgdGhlIHJvbGUgdGhh dCB3ZSB0cmFkaXRpb25hbGx5IGNhbGxlZCDigJxjbGllbnTigJ0gaW4gT0F1dGguPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBK dXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGNsaWVudCBpcyBnZXR0aW5nIGFuIGFjY2VzcyB0b2tlbiBzbyBpdCBj YW4gY2FsbCBhIHNlcnZlciwgc3BlY2lmaWNhbGx5LCBhIHJlc291cmNlIHNlcnZlciAodG8gZGlm ZmVyZW50aWF0ZSBpdCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcikuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb25mdXNpb24g aW4gbXkgZXhwZXJpZW5jZSB1c3VhbGx5IHN0ZW1zIGZyb20gcGVvcGxlIHdvcmtpbmcmbmJzcDt3 aXRoIHNvZnR3YXJlJm5ic3A7dGhhdCBpcyBhY3RpbmcgaW4gbXVsdGlwbGUmbmJzcDtyb2xlcy4g SUUsIHRoZSBzb2Z0d2FyZSZuYnNwO3RoYXQgaXMgYWN0aW5nIGFzIGEgY2xpZW50IGluIG9uY2Ug Y29udGV4dCwgaXMgYWxzbyBhY3RpbmcgYXMgYW4gUlMgaW4gb3RoZXIgY29udGV4dHMsIG9yIGV2 ZW4gYWN0aW5nIGFzIGFuDQogQVMuIFRoZSBvdGhlciBjb25mdXNpb24gaXMgdGhhdCBwZW9wbGUg dmlldyBjbGllbnRzIGFzIGJlaW5nIHRoZSBzb2Z0d2FyZSB0aGUgdXNlciBpcyB1c2luZyAtLSBh bHRob3VnaCBpdCBtYXkgbm90IGJlIGFjdGluZyBhcyBhIGNsaWVudCBpbiB0aGUgb2F1dGggY29u dGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxl PSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEwNGluIiBpZD0iX3gwMDAwX2kxMDI3IiBzcmM9Imh0 dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJX RnBiQzVqYjIwJTNEJmFtcDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPTk0OGE2YTg1LTNmMjkt NDZkZS1hZWIyLWVjYzViZjJkYjRjYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBBdWcgNiwgMjAyMCBhdCA0OjQ5IEFNIEZhYmllbiBJbWJhdWx0ICZsdDs8YSBocmVmPSJtYWls dG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFiaWVuLmltYmF1 bHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksJm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBtZSwgY2xpZW50IGhhcyBhbHdh eXMgYmVlbiBhIHN0cmFuZ2Ugd29yZCBpbiB0aGUgY29udGV4dCBvZiBPQXV0aCwgYXMgaXQgaGFz IGEgbWVhbmluZyB3ZWxsIGRlZmluZWQgYm90aCBpbiBldmVyeWRheSBsaWZlICh0aGlzIGNsaWVu dCBpcyBhIGdvb2QgY3VzdG9tZXIpIGFuZCBpbiBjb21wdXRlciBzY2llbmNlIChjbGllbnQtc2Vy dmVyIGludGVyYWN0aW9uKS4gVGh1cyBJIGFsd2F5cyBoYXZlIHRvIG1ha2UNCiB0aGUgbWVudGFs IHRyYW5zbGF0aW9uIHRvIHRoZSBPQXV0aCB3b3JsZCBiZWZvcmUgYW55IGRpc2N1c3Npb24uLi4g QW5kIGFueSB0ZWFjaGluZyBleHBlcmllbmNlIHNob3dzIHRoYXQgaXQgZG9lcyBtYWtlIHRoZSBj b25jZXB0cyBoYXJkIHRvIGdyYXNwIGZvciBhIG1ham9yaXR5IG9mIChjbGV2ZXIpIHBlb3BsZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg Zm9yIHRoZSBSTywgcHJldmlvdXMgZGlzY3Vzc2lvbnMgc3VnZ2VzdGVkIFJlc291cmNlIENvbnRy b2xsZXImbmJzcDsoUkMpJm5ic3A7YWxzbywgd2hpY2ggbWF5IGJlIGEgYml0IG1vcmUgc3BlY2lm aWMgdGhhbiBtYW5hZ2VyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWJpZW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgNiwgMjAyMCBhdCAxOjAw IFBNIERlbmlzICZsdDs8YSBocmVmPSJtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIiB0YXJnZXQ9 Il9ibGFuayI+ZGVuaXMuaWV0ZkBmcmVlLmZyPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5K dXN0aW4gYW5kIERpY2ssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+W1dhczombmJzcDsgJnF1b3Q7UmV2aXNpdGluZyB0aGUgcGhvdG8g c2hhcmluZyBleGFtcGxlIChhIGRyaXZpbmcgdXNlIGNhc2UgZm9yIHRoZSBjcmVhdGlvbiBvZiBP QXV0aCkmcXVvdDtdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+U28gbGV0IHVzIGF0dGVtcHQgdG8gZGVmaW5lIG5ldyB0ZXJtczo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5pbml0aWF0aW5nIGFwcGxpY2F0aW9uIChJQSk8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46IGFwcGxpY2F0aW9uIGJ5IG1l YW5zIG9mIHdoaWNoIGEgdXNlciBpbml0aWF0ZXMgaW50ZXJhY3Rpb25zIHdpdGggUlMocykgYW5k IEFTKHMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBzYW1lIHdheSwgd2Ugc2hvdWxkIGdldCByaWQg b2YgdGhlIHRlcm0gUmVzb3VyY2UgT3duZXIgKFJPKSwgd2hpY2ggaXMgY3VycmVudGx5IGRlZmlu ZWQgYXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+UmVzb3VyY2UgT3duZXIgKFJPKTogZW50aXR5IGNhcGFibGUgb2YgZ3JhbnRpbmcg YWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgcHJvcG9zZSB0 byByZXBsYWNlIGl0IHdpdGggUmVzb3VyY2UgTWFuYWdlciAoUk0pOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlc291cmNlIE1h bmFnZXIgKFJNKTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPiA6IGFwcGxpY2F0aW9uIG9yIHVzZXIgdGhhdCBtYW5hZ2VzIGFu IGFjY2VzcyBkZWNpc2lvbiBmdW5jdGlvbiBvZiBhIFJlc291cmNlIFNlcnZlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRl bmlzPC9zcGFuPiA8bzpwPg0KPC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFncmVlIHdpdGggSnVzdGluLiBSZWRlZmluaW5nIHdlbGwgdXNlZCB0ZXJtcyB3aWxs IGxlYWQgdG8gc2lnbmlmaWNhbnQgY29uZnVzaW9uLiBJZiB3ZSBoYXZlIGEgZGlmZmVyZW50IHJv bGUgdGhhbiB3aGF0IHdlIGhhdmUgaGFkIGluJm5ic3A7dGhlIHBhc3QsIHRoZW4gdGhhdCByb2xl IHNob3VsZCBoYXZlIGEgbmFtZSBub3QgYmVpbmcgdXNlZCBhbHJlYWR5IGluIE9BdXRoIG9yIE9J REMuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVu IHdoYXQgd2UgaGF2ZSBsZWFybmVkLCBhbmQgbXkgb3duIGV4cGVyaWVuY2UgZXhwbGFpbmluZyB3 aGF0IGEgQ2xpZW50IGlzLCBhbmQgaXMgbm90LCBpbXByb3ZpbmcgdGhlIGRlZmluaXRpb24gZm9y IENsaWVudCBjb3VsZCBwcm92ZSB1c2VmdWwuIEkgYW0gbm90IHN1Z2dlc3RpbmcgdGhlIHRlcm0g YmUgcmVkZWZpbmVkLCBidXQgY2xhcmlmaWVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgY2xhcmlmeWluZyB0 aGF0IGEgQ2xpZW50IGlzIGEgcm9sZSBhbiBlbnRpdHkgcGxheXMgaW4gdGhlIHByb3RvY29sLCBh bmQgdGhhdCB0aGUgc2FtZSBlbnRpdHkgbWF5IHBsYXkgb3RoZXIgcm9sZXMgYXQgb3RoZXIgdGlt ZXMsIG9yIHNvbWUgb3RoZXIgbGFuZ3VhZ2UgdG8gaGVscCBkaWZmZXJlbnRpYXRlIGJldHdlZW4g JnF1b3Q7cm9sZSZxdW90OyBhbmQgJnF1b3Q7ZW50aXR5JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aW1nIGJvcmRl cj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3R5bGU9IndpZHRoOi4wMTA0aW47aGVpZ2h0Oi4w MTA0aW4iIGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3Qu Y29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVy b2NvbnRlbnQmYW1wO2d1aWQ9ZTQ4ZTEzZjQtMjMwNi00ZDdjLTg2NTQtZDUwZTAwZGJhYzNhIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyA1LCAyMDIwIGF0IDg6MjAgQU0g SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0 PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGlu IGZhdm9yIG9mIGNvbWluZyB1cCB3aXRoIGEgbmV3IHRlcm0gdGhhdOKAmXMgYSBiZXR0ZXIgZml0 LCBidXQgSeKAmW0gbm90IHJlYWxseSBpbiBmYXZvciBvZiB0YWtpbmcgYW4gZXhpc3RpbmcgdGVy bSBhbmQgYXBwbHlpbmcgYSBjb21wbGV0ZWx5IG5ldyBkZWZpbml0aW9uIHRvIGl0LiBJbiBvdGhl ciB3b3JkcywgSSB3b3VsZCBzb29uZXIgc3RvcCB1c2luZyDigJxjbGllbnTigJ0gYW5kIGNvbWUg dXAgd2l0aCBhDQogbmV3LCBtb3JlIHNwZWNpZmljIGFuZCBhY2N1cmF0ZSB0ZXJtIGZvciB0aGUg cm9sZSB0aGFuIHRvIGRlZmluZSDigJxjbGllbnTigJ0gYXMgbWVhbmluZyBzb21ldGhpbmcgY29t cGxldGVseSBkaWZmZXJlbnQuIFdlIGRpZCB0aGlzIGluIGdvaW5nIGZyb20gT0F1dGggMSB0byBP QXV0aCAyIGFscmVhZHksIG1vdmluZyBmcm9tIHRoZSBldmVuLW1vcmUtY29uZnVzaW5nIOKAnGNv bnN1bWVy4oCdIHRvIOKAnGNsaWVudOKAnSwgYnV0IE9BdXRoIDIgZG9lc27igJl0IHVzZSB0aGUN CiB0ZXJtIOKAnGNvbnN1bWVy4oCdIGF0IGFsbCwgbm9yIGRvZXMgaXQgdXNlIOKAnHNlcnZlcuKA nSBvbiBpdHMgb3duIGJ1dCBpbnN0ZWFkIGFsd2F5cyBxdWFsaWZpZXMgaXQgd2l0aCDigJxBdXRo b3JpemF0aW9uIFNlcnZlcuKAnSBhbmQg4oCcUmVzb3VyY2UgU2VydmVy4oCdLg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HTkFQIGNhbiBkbyBzb21ldGhp bmcgc2ltaWxhciwgaW4gbXkgb3Bpbmlvbi4gQnV0IHdoYXQgd2UgY2Fu4oCZdCBkbyBpcyBpZ25v cmUgdGhlIGZhY3QgdGhhdCBHTkFQIGlzIGdvaW5nIHRvIGJlIGNvbWluZyB1cCBpbiBhIHdvcmxk IHRoYXQgaXMgYWxyZWFkeSBwZXJtZWF0ZWQgJm5ic3A7YnkgT0F1dGggMiBhbmQgaXRzIHRlcm1p bm9sb2d5LiBXZSBkb27igJl0IGhhdmUgYSBibGFuayBzbGF0ZSB0byB3b3JrIHdpdGgsIGJ1dA0K IG5laXRoZXIgYXJlIHdlIGJvdW5kIHRvIHVzZSB0aGUgc2FtZSB0ZXJtcyBhbmQgY29uc3RydWN0 cyBhcyBiZWZvcmUuIEl04oCZcyBnb2luZyB0byBiZSBhIGRlbGljYXRlIGJhbGFuY2UhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KA lCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgNCwgMjAyMCwgYXQgMzozMiBQTSwgV2FycmVuIFBh cmFkICZsdDs8YSBocmVmPSJtYWlsdG86d3BhcmFkQHJob3N5cy5jaCIgdGFyZ2V0PSJfYmxhbmsi PndwYXJhZEByaG9zeXMuY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgaXMgZnVuZGFtZW50YWxs eSBwYXJ0IG9mIHRoZSBxdWVzdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBjbGVhciB0aGF0IHdlIGFyZSBwcm9kdWNp bmcgYSBwcm90b2NvbCB0aGF0IGlzPGJyPg0KY29uY2VwdHVhbGx5IChpZiBub3QgbW9yZSBzdHJv bmdseSkgcmVsYXRlZCB0byBPQXV0aCAyLjAsIGFuZCByZXVzaW5nIHRlcm1zPGJyPg0KZnJvbSBP QXV0aCAyLjAgYnV0IHdpdGggZGlmZmVyZW50IGRlZmluaXRpb25zIG1heSBsZWFkIHRvIHVubmVj ZXNzYXJ5PGJyPg0KY29uZnVzaW9uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBzYXkgdGhhdCB0aGlzIGRvY3VtZW50IGFz c3VtZXMgT0F1dGgyLjAgdGVybWlub2xvZ3ksIHRoZW4gd2Ugc2hvdWxkIG5vdCBjaGFuZ2UgdGhl IG1lYW5pbmdzIG9mIGFueSBkZWZpbml0aW9uLiBJZiB3ZSBhcmUgc2F5aW5nIHRoaXMgc3VwZXJz ZWRlcyBvciByZXBsYWNlcyB3aGF0IE9BdXRoIDIuMCBjcmVhdGVzLCB0aGVuIHdlIHNob3VsZCBw aWNrIHRoZSBiZXN0IHdvcmQgZm9yIHRoZSBqb2IgYW5kDQogaWdub3JlIGNvbmZsaWN0aW5nIG1l YW5pbmdzIGZyb20gT0F1dGggMi4wLiBJIGhhdmUgYSBsb3Qgb2YgZmlyc3QgaGFuZCBleHBlcmll bmNlIG9mIGluZHVzdHJpZXMgJnF1b3Q7cnVpbmluZyB3b3JkcyZxdW90OywgYW5kIGF0dGVtcHRp bmcgdG8gc2lkZS1zdGVwIHRoZSBwcm9ibGVtIHJhdGhlciB0aGFuIHJlZGVmaW5pbmcgdGhlIHdv cmQganVzdCBjb25mdXNlcyBldmVyeW9uZSBhcyBldmVyeW9uZSBmb3JnZXRzIHRoZSBvcmlnaW5h bCBtZWFuaW5nIGFzIG5ldw0KIGRvY3VtZW50cyBjb21lIG91dCwgYnV0IHRoZSBjb25mdXNpb24g d2l0aCB0aGUgdXNlIG9mIGEgbm9uLW9idmlvdXMgd29yZCBjb250aW51ZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvb2QgZm9yIHRob3Vn aHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IFdhcnJlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIg Y2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtib3Jk ZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUu MHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Ym9yZGVyOm5v bmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIx OTkiIGhlaWdodD0iMzQiIHN0eWxlPSJ3aWR0aDoyLjA3MjlpbjtoZWlnaHQ6LjM1NDFpbiIgaWQ9 Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL2xoNi5nb29nbGV1c2VyY29udGVudC5jb20vRE5p RHgxUUdJclNxTVBLRE4xb0tldnhZdXlWUlhzcWhYZGZaT3NXNTZSZjJBNzRtVUtiQVB0ckpTTnc0 cXlua1Nqb2x0V2tQWWRCaGFaSmcxQk80NVlPYzF4czZyOUtKMWZZc05Ib2dZLW5oNmhqdUltOUdD ZUJSUnpyU2M4a1djVVNOdHVBIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVy LWxlZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRl biI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWJvdHRvbTpu b25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XYXJy ZW4gUGFyYWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZvdW5kZXIsIENU Tzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5TZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlv biBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2Jp dC5seS8zN1NTTzFwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPkF1dGhyZXNzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBBdWcgNCwgMjAyMCBhdCA4OjUzIFBNIEJlbmphbWluIEthZHVrICZsdDs8 YSBocmVmPSJtYWlsdG86a2FkdWtAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmthZHVrQG1pdC5l ZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIERlbmlzLDxicj4NCjxicj4NCk9uIFR1ZSwgQXVnIDA0LCAy MDIwIGF0IDExOjMxOjM0QU0gKzAyMDAsIERlbmlzIHdyb3RlOjxicj4NCiZndDsgSGkgSnVzdGlu LDxicj4NCiZndDsgPGJyPg0KJmd0OyBTaW5jZSB5b3UgcmVwbGllZCBpbiBwYXJhbGxlbCwgSSB3 aWxsIG1ha2UgYSByZXNwb25zZSBzaW1pbGFyIHRvIHRoZSBvbmUgPGJyPg0KJmd0OyBJIHNlbnQg dG8gRGljay48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSBEZW5pcyw8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGVyZeKAmXMgc3RpbGwgYSBwcm9ibGVtIHdpdGgg dGhlIHRlcm1pbm9sb2d5IGluIHVzZSBoZXJlLiBXaGF0IDxicj4NCiZndDsgJmd0OyB5b3UgZGVz Y3JpYmUgYXMgUlMyLCB3aGljaCBtaWdodCBpbiBmYWN0IGJlIGFuIFJTIHVudG8gaXRzZWxmLCBp cyBhIDxicj4NCiZndDsgJmd0OyDigJxDbGllbnTigJ0gaW4gT0F1dGggcGFybGFuY2UgYmVjYXVz ZSBpdCBpcyAvYSBjbGllbnQgb2YgUlMxLy4gV2hhdCB5b3UgPGJyPg0KJmd0OyAmZ3Q7IGNhbGwg YSZuYnNwO+KAnGNsaWVudOKAnSBoYXMgbm8gYW5hbG9ndWUgaW4gdGhlIE9BdXRoIHdvcmxkLCBi dXQgaXQgaXMgbm90IGF0IDxicj4NCiZndDsgJmd0OyBhbGwgdGhlIHNhbWUgYXMgYW4gT0F1dGgg Y2xpZW50LiBJIGFwcHJlY2lhdGUgeW91ciBtYXBwaW5nIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsg ZW50aXRpZXMgYmVsb3csIGJ1dCBpdCBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gaG9sZCBhIGRpc2N1 c3Npb24gaWYgd2UgPGJyPg0KJmd0OyAmZ3Q7IGFyZW7igJl0IHVzaW5nIHRoZSBzYW1lIHRlcm1z Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgdGhp cyBpc27igJl0IE9BdXRoLCBhbmQgYXMgYSBuZXcgV0cgd2UgY2FuIGRlZmluZSA8YnI+DQomZ3Q7 ICZndDsgb3VyIG93biB0ZXJtcy4gVGhlIGJhZCBuZXdzIGlzIHRoYXQgdGhpcyBpcyByZWFsbHkg aGFyZCB0byBkby48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSW4gR05BUCwgd2Ugc2hv dWxkbuKAmXQganVzdCByZS11c2UgZXhpc3RpbmcgdGVybXMgd2l0aCBuZXcgZGVmaW5pdGlvbnMs IDxicj4NCiZndDsgJmd0OyBidXQgd2XigJl2ZSBnb3QgYSBjaGFuY2UgdG8gYmUgbW9yZSBwcmVj aXNlIHdpdGggaG93IHdlIGRlZmluZSB0aGluZ3MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHRo ZSBJU08gY29udGV4dCwgZWFjaCBkb2N1bWVudCBtdXN0IGRlZmluZSBpdHMgb3duIHRlcm1pbm9s b2d5LiBUaGUgPGJyPg0KJmd0OyBib2lsZXIgcGxhdGUgZm9yIFJGQ3MgZG9lcyBub3QgbWFuZGF0 ZSBhIHRlcm1pbm9sb2d5IG9yIGRlZmluaXRpb25zIHNlY3Rpb248YnI+DQomZ3Q7IGJ1dCBkb2Vz IG5vdCBwcmV2ZW50IGl0IGVpdGhlci4gVGhlIHZvY2FidWxhcnkgaXMgbGltaXRlZCBhbmQgYXMg bG9uZyBhcyA8YnI+DQomZ3Q7IHdlIGNsZWFybHkgZGVmaW5lIHdoYXQgb3VyIHRlcm1zIGFyZSBt ZWFuaW5nLCB3ZSBjYW4gcmUtdXNlIGEgdGVybSBhbHJlYWR5PGJyPg0KJmd0OyB1c2VkIGluIGFu b3RoZXIgUkZDLiBUaGlzIGlzIGFsc28gdGhlIElTTyBhcHByb2FjaC48YnI+DQo8YnI+DQpKdXN0 IGJlY2F1c2Ugd2UgY2FuIGRvIHNvbWV0aGluZyBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIHRo YXQgaXQgaXMgYTxicj4NCmdvb2QgaWRlYSB0byBkbyBzby4mbmJzcDsgV2UgYXJlIGNsZWFyIHRo YXQgd2UgYXJlIHByb2R1Y2luZyBhIHByb3RvY29sIHRoYXQgaXM8YnI+DQpjb25jZXB0dWFsbHkg KGlmIG5vdCBtb3JlIHN0cm9uZ2x5KSByZWxhdGVkIHRvIE9BdXRoIDIuMCwgYW5kIHJldXNpbmcg dGVybXM8YnI+DQpmcm9tIE9BdXRoIDIuMCBidXQgd2l0aCBkaWZmZXJlbnQgZGVmaW5pdGlvbnMg bWF5IGxlYWQgdG8gdW5uZWNlc3Nhcnk8YnI+DQpjb25mdXNpb24uJm5ic3A7IElmIEkgdW5kZXJz dGFuZCBjb3JyZWN0bHksIGEgc2ltaWxhciByZWFzb25pbmcgcHJvbXB0ZWQgRGljayB0bzxicj4N CnVzZSB0aGUgdGVybSAmcXVvdDtHUyZxdW90OyBpbiBYQXV0aCwgcGlja2luZyBhIG5hbWUgdGhh dCB3YXMgbm90IGFscmVhZHkgdXNlZCBpbjxicj4NCk9BdXRoIDIuMC48YnI+DQo8YnI+DQotQmVu PGJyPg0KPGJyPg0KLS0gPGJyPg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NClRYQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VFhBdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+VFhBdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpUWEF1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+ DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIg Y2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJhbmNp cyBQb3VhdGNoYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q28tRm91bmRlciBhbmQgVGVjaG5pY2FsIExlYWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFkb3JzeXMgR21iSCAmYW1wOyBDby4gS0c8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vYWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9hZG9yc3lzLXBsYXRmb3JtLmRlL3NvbHV0aW9ucy88L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpUWEF1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRYQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Z3JheSI+TW9uZXlodWIgRW50ZXJwcmlzZSBpcyBh IHRyYWRpbmcgc3R5bGUgb2YgTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgTGltaXRlZCB3 aGljaCBpcyBhdXRob3Jpc2VkIGFuZCByZWd1bGF0ZWQgYnkgdGhlIEZpbmFuY2lhbCBDb25kdWN0 IEF1dGhvcml0eSAoJnF1b3Q7RkNBJnF1b3Q7KS4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xv Z3kNCiBpcyBlbnRlcmVkIG9uIHRoZSBGaW5hbmNpYWwgU2VydmljZXMgUmVnaXN0ZXIgKEZSTiA4 MDkzNjApIGF0IDxhIGhyZWY9Imh0dHBzOi8vcmVnaXN0ZXIuZmNhLm9yZy51ay8iIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vcmVnaXN0ZXIuZmNhLm9yZy51ay88L2E+LiBNb25leWh1YiBGaW5h bmNpYWwgVGVjaG5vbG9neSBpcyByZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMsIGNv bXBhbnkgcmVnaXN0cmF0aW9uIG51bWJlciAwNjkwOTc3Mi4gTW9uZXlodWIgRmluYW5jaWFsIFRl Y2hub2xvZ3kgTGltaXRlZCAyMDIwIMKpIE1vbmV5aHViIEVudGVycHJpc2UsIFJlZ3VzIEJ1aWxk aW5nLCBUZW1wbGUgUXVheSwgMSBGcmlhcnksIEJyaXN0b2wsIEJTMSA2RUEuJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9iPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpncmF5Ij5ESVNDTEFJ TUVSOiBUaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBzdWJqZWN0IHRv IGNvcHlyaWdodCwgYW5kIHRoZSBpbmZvcm1hdGlvbiBpbiBpdCBpcyBjb25maWRlbnRpYWwuIFVz ZSBvZiB0aGlzIGVtYWlsIG9yIG9mIGFueSBpbmZvcm1hdGlvbiBpbiBpdCBvdGhlciB0aGFuIGJ5 IHRoZQ0KIGFkZHJlc3NlZSBpcyB1bmF1dGhvcmlzZWQgYW5kIHVubGF3ZnVsLiBXaGlsc3QgcmVh c29uYWJsZSBlZmZvcnRzIGFyZSBtYWRlIHRvIGVuc3VyZSB0aGF0IGFueSBhdHRhY2htZW50cyBh cmUgdmlydXMtZnJlZSwgaXQgaXMgdGhlIHJlY2lwaWVudCdzIHNvbGUgcmVzcG9uc2liaWxpdHkg dG8gc2NhbiBhbGwgYXR0YWNobWVudHMgZm9yIHZpcnVzZXMuIEFsbCBjYWxscyBhbmQgZW1haWxz IHRvIGFuZCBmcm9tIHRoaXMgY29tcGFueSBtYXkgYmUgbW9uaXRvcmVkDQogYW5kIHJlY29yZGVk IGZvciBsZWdpdGltYXRlIHB1cnBvc2VzIHJlbGF0aW5nIHRvIHRoaXMgY29tcGFueSdzIGJ1c2lu ZXNzLiBBbnkgb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZW1haWwgKG9yIGluIGFueSBhdHRh Y2htZW50cykgYXJlIHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSBy ZXByZXNlbnQgdGhlIG9waW5pb25zIG9mIE1vbmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IExp bWl0ZWQgb3Igb2YgYW55DQogb3RoZXIgZ3JvdXAgY29tcGFueS48L3NwYW4+PGI+PG86cD48L286 cD48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0gPGJyPg0KVFhBdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5UWEF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB0684496FAFF843EF4286B0ECF5451DM6PR00MB0684namp_-- From nobody Tue Aug 11 10:02:47 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 077333A0836 for ; Tue, 11 Aug 2020 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 q_kyqgpFQyfM for ; Tue, 11 Aug 2020 10:02:43 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 9815F3A0857 for ; Tue, 11 Aug 2020 10:02:42 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id w14so14346876ljj.4 for ; Tue, 11 Aug 2020 10:02:42 -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=0Kfabs5524/l9WaQtDe8Vj+1ICG0BH34GHjnceThnYc=; b=n6NAPcY0vWv8I24XEXp87WZZmyTNwB/9EgDcuD4YoYzz6mJBvOlpkzJ0MjHWTNki5p O7aR+fp4naK9C7+Ieurv8hqPexWSl9Dzpd2Jrr7Zk6OVbSig1hURETOQsjpCldOHmpnw 7P50klrQteqKaFQlmwiM5gJafox+D2d/JPYCyR5YPKgg5+VBkjh0VZ7knijxDcaABcbN wkWvQcvYPmUdn+zxTioyre4OxhS87Ljby5mOjwWOcJpI9a35I4Aiawt4Vyz6DMi9aJio KHU5nsSizVPVZy0RX6wZ3HDJ2nqWj8sYN8Bw5lAT0jSgAE3mThbyYgMafEO8mL1XEkTS P9tA== 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=0Kfabs5524/l9WaQtDe8Vj+1ICG0BH34GHjnceThnYc=; b=Bk+s2NaraIIL/RCrwgUs9Wg9W7EcSRFGAhKGBQQ14Jycl3fZHZO40H5pg2fFHZJ5rz 5GpOY07FynHbDWxT7m/1qQHh28sN6jeCL9dtRUptbOD+Xk1yUXWCtruMCEDNaXUIuwHe WjGPtQKLUFyPzNxWFaKTjNXPJ2m4/C6IpnXO/0TUKCuLQiL07pLgWkr3hFfEAn4r4Pzg sbxI91DCnSVkUA6kYVKeGqy9cUNDkkxTkWIxxlL5qP8bNhhWFp0CctnSLwMWeGbTWc+Z arZQaO1bgWI/K0ZfdvSnKjjiBp2arFrbUbgs601gIWoFgrZFB3nkZOKNCnbiwgp2QoMo Mb1Q== X-Gm-Message-State: AOAM5332f3gM54nXTdEXa0MSN48Vdd2zWSY2dEMv7K1dEWqNjjwgzqJc LuThjVJDnKSenJVVh3mcftm8DduwEO3/M1vK4kc= X-Google-Smtp-Source: ABdhPJxTm8c4GXQdVs/wbAS0iJgFHIFho/qRcjHOCMPT7NaWXUwtiqqfv3cyukclwDwPs/7OlhT2XN2HVi6LwxQUqiM= X-Received: by 2002:a2e:865a:: with SMTP id i26mr3244344ljj.246.1597165360555; Tue, 11 Aug 2020 10:02:40 -0700 (PDT) MIME-Version: 1.0 References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 10:02:04 -0700 Message-ID: To: Mike Jones Cc: Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f6a94205ac9d090f" Archived-At: Subject: Re: [GNAP] Design team formed 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, 11 Aug 2020 17:02:45 -0000 --000000000000f6a94205ac9d090f Content-Type: text/plain; charset="UTF-8" Leif / Yaron: thanks for organizing! Kathleen, Mike, Fabien: thanks for stepping up. Mike: I have a number of adjustments I had queued for a new version prior to the WG meeting, but I did not think it was useful to push new concepts or material given the path to have a design team. On Tue, Aug 11, 2020 at 9:14 AM Mike Jones wrote: > Thanks for your confidence in me and the rest of the design team. I plan > to read both individual specs cover-to-cover as part of my preparation for > this work. > > Dick and Justin, are there additional edits you plan to publish before I > should do my review, or should I review the currently published drafts? > > Thanks, > -- Mike > > -----Original Message----- > From: TXAuth On Behalf Of Yaron Sheffer > Sent: Tuesday, August 11, 2020 3:43 AM > To: GNAP Mailing List > Subject: [GNAP] Design team formed > > Thank you all for attending the inaugural GNAP meeting at IETF-108. We had > quite a few volunteers, and the chairs picked the following people for the > design team: > > * Kathleen Moriarty > * Justin Richer > * Dick Hardt > * Mike Jones > * Fabien Imbault > > Kathleen has graciously agreed to convene the sessions and report on the > team's outcome. Thank you all who volunteered! > > We expect the design team to decide on a solution outline that combines > the best of both proposals, and present this outline by Sep. 15. Anything > is as usual subject to approval by the whole working group. > > Thanks, > Leif and Yaron > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f6a94205ac9d090f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Leif / Yaron: thanks for organizing!

Ka= thleen, Mike, Fabien: thanks for stepping up.

Mike= : I have a number of adjustments I had queued for a new version prior to th= e WG meeting, but I did not think it was useful to push new concepts or mat= erial given=C2=A0the path to have a design team.=C2=A0

=

= On Tue, Aug 11, 2020 at 9:14 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>= ; wrote:
Thanks = for your confidence in me and the rest of the design team.=C2=A0 I plan to = read both individual specs cover-to-cover as part of my preparation for thi= s work.

Dick and Justin, are there additional edits you plan to publish before I sh= ould do my review, or should I review the currently published drafts?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent: Tuesday, August 11, 2020 3:43 AM
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] Design team formed

Thank you all for attending the inaugural GNAP meeting at IETF-108. We had = quite a few volunteers, and the chairs picked the following people for the = design team:

* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron



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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f6a94205ac9d090f-- From nobody Tue Aug 11 10:25:17 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 BD7183A084C for ; Tue, 11 Aug 2020 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TyY5iOBN2zVS for ; Tue, 11 Aug 2020 10:25:12 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3477B3A0847 for ; Tue, 11 Aug 2020 10:25:11 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d06 with ME id EHR42300A2bcEcA03HR5eB; Tue, 11 Aug 2020 19:25:09 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 11 Aug 2020 19:25:09 +0200 X-ME-IP: 90.79.51.120 To: Mike Jones , Tom Jones , Dave Tonge Cc: Francis Pouatcha , Justin Richer , Dick Hardt , Benjamin Kaduk , Fabien Imbault , "txauth@ietf.org" References: From: Denis Message-ID: <63a40d80-e7b3-4016-d92c-f1889fe62dfe@free.fr> Date: Tue, 11 Aug 2020 19:25:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------169998FF4A838E80D85F2C33" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 17:25:16 -0000 This is a multi-part message in MIME format. --------------169998FF4A838E80D85F2C33 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To all, We are circling around. In order to progress about the terminology, I propose the following: 1° Adopt the ISO rule for a definition: The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop. A definition shall not take the form of, or contain, a requirement. 2° Propose at the same time a term AND its definition. 3° If you don't like a term or its definition proposed by someone else, this is fine ... but only as long as you have a counter proposal for either the term and/or its definition. As an example, only stating that " "client" can be confusing" would not be a valid proposal. Terms and definitions are used in the context of RFCs issued by a WG and it is fine using terms already used by other RFCs issued by another WG as long as we clearly define them. Denis > One of the things that people hated about OAuth was it invented new > terminology that wasn’t in common use.  But for better or for worse, > the terms Client, Authorization Server, and Protected Resource are now > widely understood. > > Let’s not make people similarly hate GNAP by inventing even more novel > terms, when existing terms will fit the bill.  Client wasn’t a perfect > choice but adding “Orchestrator” to the vocabulary menagerie would > definitely make things worse. > >                                          -- Mike > > *From:* TXAuth *On Behalf Of *Tom Jones > *Sent:* Tuesday, August 11, 2020 8:44 AM > *To:* Dave Tonge > *Cc:* Francis Pouatcha ; Justin Richer > ; Dick Hardt ; Benjamin Kaduk > ; Fabien Imbault ; Denis > ; txauth@ietf.org > *Subject:* Re: [GNAP] Terminology > > the term "orchestator" does not match any use case i have. > > Let's be clear that there are four entities to a single transaction in > the real world sense of things. (and others that support the  > transaction.) > > Then we can focus on the end point roles. I will focus on the data > privacy issues, API's have the same parties with different terminology. > > 1. the subject of the data to be transferred. > > 2. the user of a grant from the subject to act as delegate. (see > https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the > user) > > 3. the site that has a repository of user data with legal obligations > to protect that data (the GDPR) (role resource server.) > > 4 the site that wants either access to the data, or some privacy > preserving statement about the existence and content of the data. > (role of client, vendor, PISP, etc.) > > 5. some sorts of facilitator sites for allowing access (roles like > authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been > left out of OAUTH for good reason. > > This is a note supporting the separation of roles from legal > entities.  BTW, I firmly believe that the legal entity also needs to > be ID'd by the transaction. > > Peace ..tom > > On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: > > Hi all > > I agree that "client" can be confusing. I would be in support of > alternative terminology. > > We can always have some wording that explains that an > "Orchestrator" in GNAP plays a similar role to "Client" in OAuth. > > Dave > > On Tue, 11 Aug 2020 at 07:52, Fabien Imbault > > wrote: > > Hi Francis, > > I like your proposal, seems much more intuitive. > > Fabien > > Le mar. 11 août 2020 à 04:17, Francis Pouatcha > a écrit : > > Hello Denis, Justin, Dick, Fabien, > > In this post > (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) > i suggested we use the word "Orchestrator" to designate > the piece of software that orchestrate interaction between > "Requestor" (a.k.a. User), AS and RS to obtain the > protected resource. > > We are turning around the same topic. As soon as we go > beyond the original oAuth protocol, the word 'Client' > becomes confusing. > > In the same response, I suggest we talk about "roles" and > not "entities". > > Best regards. > > /Francis > > On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > > wrote: > > I still think that client was the right name in OAuth > 2, as the client wanted to do a client-server > interaction, so the client used OAuth 2 to get an > access token to interact with the "server". > > I do agree that it is not the best term in GNAP. > Primarily because GNAP is a combination of the client > from OAuth 2, and the relying party from OIDC. > > /Dick > > ᐧ > > On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > > wrote: > > On Aug 6, 2020, at 12:53 PM, Dick Hardt > > wrote: > > The term client in OAuth came from the > computer science definition of client-server > interaction. > > This, I would argue, is exactly why it’s a bad > label for something that’s distinctly more > specific in this context, and I would love to see > GNAP adopt a more specific label for the role that > we traditionally called “client” in OAuth. > >  — Justin > > > > The client is getting an access token so it > can call a server, specifically, a resource > server (to differentiate it from the > authorization server). > > The confusion in my experience usually stems > from people working with software that is > acting in multiple roles. IE, the > software that is acting as a client in once > context, is also acting as an RS in other > contexts, or even acting as an AS. The other > confusion is that people view clients as being > the software the user is using -- although it > may not be acting as a client in the oauth > context. > > ᐧ > > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault > > wrote: > > Hi, > > To me, client has always been a strange > word in the context of OAuth, as it has a > meaning well defined both in everyday life > (this client is a good customer) and in > computer science (client-server > interaction). Thus I always have to make > the mental translation to the OAuth world > before any discussion... And any teaching > experience shows that it does make the > concepts hard to grasp for a majority of > (clever) people. > > As for the RO, previous discussions > suggested Resource Controller (RC) also, > which may be a bit more specific than > manager. > > Fabien > > On Thu, Aug 6, 2020 at 1:00 PM Denis > > wrote: > > Justin and Dick, > > [Was:  "Revisiting the photo sharing > example (a driving use case for the > creation of OAuth)"] > > So let us attempt to define new terms: > > *initiating application (IA)*: > application by means of which a > user initiates interactions with > RS(s) and AS(s) > > In the same way, we should get rid of > the term Resource Owner (RO), which is > currently defined as: > > Resource Owner (RO): entity > capable of granting access to a > protected resource > > I propose to replace it with Resource > Manager (RM): > > *Resource Manager (RM)*: > application or user that manages > an access decision function of a > Resource Server > > Denis > > I agree with Justin. Redefining > well used terms will lead to > significant confusion. If we have > a different role than what we have > had in the past, then that role > should have a name not being used > already in OAuth or OIDC. > > Given what we have learned, and my > own experience explaining what a > Client is, and is not, improving > the definition for Client could > prove useful. I am not suggesting > the term be redefined, but clarified. > > For example, clarifying that a > Client is a role an entity plays > in the protocol, and that the same > entity may play other roles at > other times, or some other > language to help differentiate > between "role" and "entity". > > /Dick > > ᐧ > > On Wed, Aug 5, 2020 at 8:20 AM > Justin Richer > wrote: > > I’m in favor of coming up with > a new term that’s a better > fit, but I’m not really in > favor of taking an existing > term and applying a completely > new definition to it. In other > words, I would sooner stop > using “client” and come up > with a new, more specific and > accurate term for the role > than to define “client” as > meaning something completely > different. We did this in > going from OAuth 1 to OAuth 2 > already, moving from the > even-more-confusing “consumer” > to “client”, but OAuth 2 > doesn’t use the term > “consumer” at all, nor does it > use “server” on its own but > instead always qualifies it > with “Authorization Server” > and “Resource Server”. > > GNAP can do something similar, > in my opinion. But what we > can’t do is ignore the fact > that GNAP is going to be > coming up in a world that is > already permeated  by OAuth 2 > and its terminology. We don’t > have a blank slate to work > with, but neither are we bound > to use the same terms and > constructs as before. It’s > going to be a delicate balance! > >  — Justin > > > > On Aug 4, 2020, at 3:32 > PM, Warren Parad > > > wrote: > > I think that is > fundamentally part of the > question: > > We are clear that we > are producing a > protocol that is > conceptually (if not > more strongly) related > to OAuth 2.0, and > reusing terms > from OAuth 2.0 but > with different > definitions may lead > to unnecessary > confusion > > If we say that this > document assumes OAuth2.0 > terminology, then we > should not change the > meanings of any > definition. If we are > saying this supersedes or > replaces what OAuth 2.0 > creates, then we should > pick the best word for the > job and ignore conflicting > meanings from OAuth 2.0. I > have a lot of first hand > experience of industries > "ruining words", and > attempting to side-step > the problem rather than > redefining the word just > confuses everyone as > everyone forgets the > original meaning as new > documents come out, but > the confusion with the use > of a non-obvious word > continues. > > Food for thought. > > - Warren > > > > > *Warren Parad* > > Founder, CTO > > Secure your user data and > complete your > authorization > architecture. Implement > Authress > . > > On Tue, Aug 4, 2020 at > 8:53 PM Benjamin Kaduk > > wrote: > > Hi Denis, > > On Tue, Aug 04, 2020 > at 11:31:34AM +0200, > Denis wrote: > > Hi Justin, > > > > Since you replied in > parallel, I will make > a response similar to > the one > > I sent to Dick. > > > > > Hi Denis, > > > > > > I think there’s > still a problem with > the terminology in use > here. What > > > you describe as > RS2, which might in > fact be an RS unto > itself, is a > > > “Client” in OAuth > parlance because it is > /a client of RS1/. > What you > > > call a “client” > has no analogue in the > OAuth world, but it is > not at > > > all the same as an > OAuth client. I > appreciate your > mapping of the > > > entities below, > but it makes it > difficult to hold a > discussion if we > > > aren’t using the > same terms. > > > > > > The good news is > that this isn’t OAuth, > and as a new WG we can > define > > > our own terms. The > bad news is that this > is really hard to do. > > > > > > In GNAP, we > shouldn’t just re-use > existing terms with > new definitions, > > > but we’ve got a > chance to be more > precise with how we > define things. > > > > In the ISO context, > each document must > define its own > terminology. The > > boiler plate for > RFCs does not mandate > a terminology or > definitions section > > but does not prevent > it either. The > vocabulary is limited > and as long as > > we clearly define > what our terms are > meaning, we can re-use > a term already > > used in another RFC. > This is also the ISO > approach. > > Just because we can do > something does not > necessarily mean that > it is a > good idea to do so.  > We are clear that we > are producing a > protocol that is > conceptually (if not > more strongly) related > to OAuth 2.0, and > reusing terms > from OAuth 2.0 but > with different > definitions may lead > to unnecessary > confusion.  If I > understand correctly, > a similar reasoning > prompted Dick to > use the term "GS" in > XAuth, picking a name > that was not already > used in > OAuth 2.0. > > -Ben > > -- > Txauth mailing list > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > 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/ > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > *Moneyhub Enterprise is a trading style of Moneyhub Financial > Technology Limited which is authorised and regulated by the > Financial Conduct Authority ("FCA"). Moneyhub Financial Technology > is entered on the Financial Services Register (FRN 809360) at > https://register.fca.org.uk/ . > Moneyhub Financial Technology is registered in England & Wales, > company registration number 06909772. Moneyhub Financial > Technology Limited 2020 © Moneyhub Enterprise, Regus Building, > Temple Quay, 1 Friary, Bristol, BS1 6EA. * > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this > email or of any information in it other than by the addressee is > unauthorised and unlawful. Whilst reasonable efforts are made to > ensure that any attachments are virus-free, it is the recipient's > sole responsibility to scan all attachments for viruses. All calls > and emails to and from this company may be monitored and recorded > for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those > of the author and do not necessarily represent the opinions of > Moneyhub Financial Technology Limited or of any other group company.** > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------169998FF4A838E80D85F2C33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
To all,

We are circling around. In order to progress about the terminology, I propose the following:

1° Adopt the ISO rule for a definition:
The definition shall be written in such a form that it can replace the term in its context.
It shall not start with an article (“the”, “a”) nor end with a full stop.
A definition shall not take the form of, or contain, a requirement.
2° Propose at the same time a term AND its definition.

3° If you don't like a term or its definition proposed by someone else, this is fine ... but only as long as
you have a counter proposal for either the term and/or its definition. As an example, only stating that
" "client" can be confusing" would not be a valid proposal.

Terms and definitions are used in the context of RFCs issued by a WG and it is fine using terms
already used by other RFCs issued by another WG as long as we clearly define them.

Denis

One of the things that people hated about OAuth was it invented new terminology that wasn’t in common use.  But for better or for worse, the terms Client, Authorization Server, and Protected Resource are now widely understood.

 

Let’s not make people similarly hate GNAP by inventing even more novel terms, when existing terms will fit the bill.  Client wasn’t a perfect choice but adding “Orchestrator” to the vocabulary menagerie would definitely make things worse.

 

                                                       -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

 

the term "orchestator" does not match any use case i have.

Let's be clear that there are four entities to a single transaction in the real world sense of things. (and others that support the  transaction.)

Then we can focus on the end point roles. I will focus on the data privacy issues, API's have the same parties with different terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the user)

3. the site that has a repository of user data with legal obligations to protect that data (the GDPR) (role resource server.)

4 the site that wants either access to the data, or some privacy preserving statement about the existence and content of the data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

 

This is a note supporting the separation of roles from legal entities.  BTW, I firmly believe that the legal entity also needs to be ID'd by the transaction.

Peace ..tom

 

 

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:

Hi all

 

I agree that "client" can be confusing. I would be in support of alternative terminology.

We can always have some wording that explains that an "Orchestrator" in GNAP plays a similar role to "Client" in OAuth.

 

Dave

 

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Francis,

 

I like your proposal, seems much more intuitive. 

 

Fabien 

 

Le mar. 11 août 2020 à 04:17, Francis Pouatcha <fpo@adorsys.de> a écrit :

Hello Denis, Justin, Dick, Fabien,

 

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between "Requestor" (a.k.a. User), AS and RS to obtain the protected resource. 

 

We are turning around the same topic. As soon as we go beyond the original oAuth protocol, the word 'Client' becomes confusing.

 

In the same response, I suggest we talk about "roles" and not "entities".

 

Best regards.

/Francis

 

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the right name in OAuth 2, as the client wanted to do a client-server interaction, so the client used OAuth 2 to get an access token to interact with the "server".

 

I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC. 

 

/Dick

ᐧ

 

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

 

The term client in OAuth came from the computer science definition of client-server interaction.

 

This, I would argue, is exactly why it’s a bad label for something that’s distinctly more specific in this context, and I would love to see GNAP adopt a more specific label for the role that we traditionally called “client” in OAuth.

 

 — Justin



 

The client is getting an access token so it can call a server, specifically, a resource server (to differentiate it from the authorization server).

 

The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context.

 

 

 

ᐧ

 

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

 

To me, client has always been a strange word in the context of OAuth, as it has a meaning well defined both in everyday life (this client is a good customer) and in computer science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any teaching experience shows that it does make the concepts hard to grasp for a majority of (clever) people.

 

As for the RO, previous discussions suggested Resource Controller (RC) also, which may be a bit more specific than manager. 

 

Fabien 

 

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wrote:

Justin and Dick,

 

[Was:  "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]

 

So let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)

In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:

Resource Owner (RO): entity capable of granting access to a protected resource

I propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user that manages an access decision function of a Resource Server

Denis

 

I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

 

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

 

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

 

/Dick

ᐧ

 

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit.edu> wrote:

I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

 

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 

 — Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

 

I think that is fundamentally part of the question:

We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

 

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

 

Food for thought.

- Warren

Warren Parad

Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress.

 

 

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

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

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

 

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

 

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

 

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


 

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

 

 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.


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


--------------169998FF4A838E80D85F2C33-- From nobody Tue Aug 11 10:25:24 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 5AEE33A0847 for ; Tue, 11 Aug 2020 10:25:21 -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 LjTNNyzmLQbH for ; Tue, 11 Aug 2020 10:25:19 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 6A36A3A08FF for ; Tue, 11 Aug 2020 10:25:19 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id t14so3602118wmi.3 for ; Tue, 11 Aug 2020 10:25:19 -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=fotzKGBZ5Aj3wNwqASSgLoy/Co7MpFhUWBvPCsY+IJY=; b=Os1KkXHK79X2uP9xscjjzlOwKg9n/a2BazWma+GMtx7sLu1LA4HGk1DROjredZ4jWg E2oZ4rMZ/kUb7ybkgMTXR4THYbZLcj/CS0u9j8z/PisWdTv/euwGgYY60/OkNLUgN+pa lZSyuvTe0A9GsNkzR++3vNbsgLwijE5M6cq6A= 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=fotzKGBZ5Aj3wNwqASSgLoy/Co7MpFhUWBvPCsY+IJY=; b=eRv56TIBh5Jhn8fCEZB8ULLr1H3Tty4OslFBCP2QqqunZScjvvt3DIdekwraUi7w9Y ljrb6Y6BBjsoIOFrPoqGBtqao7++nlNJb4Qme3VfmLkyL4udFX75L/ma3yNWEVOXBVG6 F2o5hSVtCMsGTlIjFlKT3kmSGfLqpMudUCOWyxzQaBepk6Gq6kjaVf5KWLbUtU9Ia9vH hSUITDBn11OST1aZ9pgndy7wMnBwd02OEzUbZk3ynNuejC1t/NEoYzySbVfM3D/Mj+om H3kjc02xEXVf5ddj14q2hMTspFQGmeMq71RCcq/8Nkxd6P44Bc9VlbXGHGNTnm/z0H9V CGXA== X-Gm-Message-State: AOAM532hG4OZuPdrrg9NaXTf/PiRsIfZAJ46PFNbLcwvxz/IMKnL6Pnx s2JgGclSmPW5SaT0KhHN00/4ALy4FPMUZrOiNFee9Q== X-Google-Smtp-Source: ABdhPJyCWDEiJTYx3OkL8KvWBTI6Az5ahYDImAlUydF9W+tlxRkp0fw+9SxjTHcfh+TB/jB/mBbNhRVflGS/VuPZRh0= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr4659358wml.38.1597166717638; Tue, 11 Aug 2020 10:25:17 -0700 (PDT) MIME-Version: 1.0 References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> In-Reply-To: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> From: Francis Pouatcha Date: Tue, 11 Aug 2020 13:25:06 -0400 Message-ID: To: Yaron Sheffer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000da333c05ac9d5ab9" Archived-At: Subject: Re: [GNAP] Design team formed 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, 11 Aug 2020 17:25:23 -0000 --000000000000da333c05ac9d5ab9 Content-Type: text/plain; charset="UTF-8" It is unfortunate I didn't make it. Would have liked to bring in my 22 years of experience in building authz applications. Best regards. /Francis On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer wrote: > Thank you all for attending the inaugural GNAP meeting at IETF-108. We had > quite a few volunteers, and the chairs picked the following people for the > design team: > > * Kathleen Moriarty > * Justin Richer > * Dick Hardt > * Mike Jones > * Fabien Imbault > > Kathleen has graciously agreed to convene the sessions and report on the > team's outcome. Thank you all who volunteered! > > We expect the design team to decide on a solution outline that combines > the best of both proposals, and present this outline by Sep. 15. Anything > is as usual subject to approval by the whole working group. > > Thanks, > Leif and Yaron > > > > -- > 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/ --000000000000da333c05ac9d5ab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is unfortunate I didn't make it. Would have liked t= o bring in my 22 years of experience in building authz applications.
Best regards.
/Francis

On Tue, Aug 11, 2020 at = 6:43 AM Yaron Sheffer <yaronf.i= etf@gmail.com> wrote:
Thank you all for attending the inaugural GNAP meeting at IETF= -108. We had quite a few volunteers, and the chairs picked the following pe= ople for the design team:

* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron



--
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/
--000000000000da333c05ac9d5ab9-- From nobody Tue Aug 11 12:26:01 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 0D1763A07FF for ; Tue, 11 Aug 2020 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 Znq8zaT7T2Bf for ; Tue, 11 Aug 2020 12:25:55 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 22E9C3A0ACF for ; Tue, 11 Aug 2020 12:25:55 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id m15so7284887lfp.7 for ; Tue, 11 Aug 2020 12:25:55 -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=xMXJ9wawOWlZZu2kaGUS3izclPD/6HRdL3XkHUHU4MA=; b=VSlbC/oAlXyAXPTIiAaY6d9g2Sh1iFTNjBqbiJfpnSXXZJoofGfcOdbrysCxqH3fAs K5/0OJ+06J/jG/fhFSSH3N2d1FjISmryfol0t9rk48EvH0kVSdzL255p8dQchRbBgoFs ereVQh83cIYWKdoeWgCOOVgMnXJlMyCRKl+ZJ1UnJHei2F2EX7vy8f5JJ8YyfBIYWa1K MnkPwujUe1Nqdla4U+zTMMiAY7nt5NtxKQqWwAYFGZ6oTxnM084GKPpLnzO/Xf0YvPUY Cb1RRSIRdALuU0v0adRvECPKGB8ONKjSBZG7PLGXGkICkFiqqWpX+8WA87CqLBWLuqxz EMHg== 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=xMXJ9wawOWlZZu2kaGUS3izclPD/6HRdL3XkHUHU4MA=; b=MklpQAeSkePneH5iPNY1tKCY6YG8Z6mPPBbLbBGrH/o/7IMzI8fDM1Spf7prP1nlha SlBSl6Svm9d1iCKjjfgTFwFFJK9IyP0RudQ2C3u30x5GZAWZKZpYStvuCERR2tXip9mQ gU56wVPLIx5Wz86ST2Hrbk45LKoht/p1zp3AgL9tGaMErgiHZXmLAtev8z54BgIEhybH GDh5S1StJUW/J469tL68Zo8wyQN/XheM6BQyCKXkPWvDunHCOQkIuRV2ZNMbTr2OfUMy SQNEBXUvLshrGmOqL2CIcb1LMHiDwUir6Ke5UtQgF5Qr8r6sQf0ZEJ1aj7CUk32nWqyy 8T5g== X-Gm-Message-State: AOAM530g4oCLEW8vlL/pX+BpU7zEibcSPQqzfpZ0K/FzWuxW5XxlkqQ0 rMp3/LagCM+57pahqKtGAfnnTph6ifvYSpCJMxY= X-Google-Smtp-Source: ABdhPJysoeR+ITr56RRVt8naICZ7xR8vPhTRg98NTjwY83LgwuNKVmC7NcIguLe0kWJfg7OjDghRaDM6EcUkoKWLQ1E= X-Received: by 2002:a19:70c:: with SMTP id 12mr3905986lfh.207.1597173952980; Tue, 11 Aug 2020 12:25:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 12:25:16 -0700 Message-ID: To: Mike Jones Cc: Tom Jones , Dave Tonge , Francis Pouatcha , Justin Richer , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001cab2305ac9f0a20" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 19:25:59 -0000 --0000000000001cab2305ac9f0a20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I echo Mike's comments on preserving names when possible. The shift from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. I also echo Tom's comments about separating Entities from Roles. Orchestration[1] in my opinion is not what the "client" is doing. Below is a stab at separating the entities and the roles /Dick *Tl;dr: * - Client -> Grant Client - added Relying Party, Claims Issuer, and Grant Server Operator as entities *Roles* - parties to the protocol Grant Client (GC), Grant Server (GS), Resource Server (RS) *Entities* - parties to a Trust Framework User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operator (GSO), Resource Owner (RO) *Grant *- may contain claims and/or access to resources *#Protocol Roles* *Grant Client* (GC) - used by User - operated / provided by RP - requests Grants from the GS - access resources at an RS - consumes Claims *Grant Server* (GS) - operated by GSO - may interact with the User - may interact with the RO - accepts grant requests from GCs - issues grants to GCs - may issue claims *Resource Server* (RS) - manages access to resources for the RO - provides access to resources for the GC - accepts access granted by the GS *#Legal Entities* *User* - uses Grant Client - may interact with the Grant Server - may also be a RO - trusts RP, Issuer, GSO *Relying Party* (RP) - provides Grant Client to the User. - may trust Issuers, GSOs, and ROs *Claims Issuer* (Issuer) - issues claims to RP - may use GS or RS to issue claims *Grant Server Operator* (GSO) - operates the GS - trusted by User, RP, and RO - may also be an Issuer *Resource Owne*r (RO) - owns resources at the RS - trusts GSO to control access to the resources - may be same entity as the User - may also be an Issuer [1] https://en.wikipedia.org/wiki/Orchestration_(computing) Orchestration (computing) >From Wikipedia, the free encyclopedia Jump to navigation Jump to search In system administration , *orchestration* is the automated configuration , coordination, and management of computer systems and software .[1] A number of tools exist for automation of server configuration and management, including Ansible , Puppet , Salt , Terraform ,[2] and A= WS CloudFormation .[3] Usage[edit ] Orchestration is often discussed in the context of service-oriented architecture , virtualization , provisioning , converged infrastructure and dynamic datacenter topics. Orchestration in this sense is about aligning the business request with the applications, data, and infrastructure.[4] In the context of cloud computing , the main difference between workflow automation and orchestration is that workflows are processed and completed as processes within a single domain for automation purposes, whereas orchestration includes a workflow and provides a directed action towards larger goals and objectives.[1] In this context, and with the overall aim to achieve specific goals and objectives (described through quality of service parameters), for example, meet application performance goals using minimized cost[5] and maximize application performance within budget constraints.[6] On Tue, Aug 11, 2020 at 9:33 AM Mike Jones wrote: > One of the things that people hated about OAuth was it invented new > terminology that wasn=E2=80=99t in common use. But for better or for wor= se, the > terms Client, Authorization Server, and Protected Resource are now widely > understood. > > > > Let=E2=80=99s not make people similarly hate GNAP by inventing even more = novel > terms, when existing terms will fit the bill. Client wasn=E2=80=99t a pe= rfect > choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary menage= rie would > definitely make things worse. > > > > -- Mike > > > > *From:* TXAuth *On Behalf Of *Tom Jones > *Sent:* Tuesday, August 11, 2020 8:44 AM > *To:* Dave Tonge > *Cc:* Francis Pouatcha ; Justin Richer ; > Dick Hardt ; Benjamin Kaduk ; Fabien > Imbault ; Denis ; > txauth@ietf.org > *Subject:* Re: [GNAP] Terminology > > > > the term "orchestator" does not match any use case i have. > > Let's be clear that there are four entities to a single transaction in th= e > real world sense of things. (and others that support the transaction.) > > Then we can focus on the end point roles. I will focus on the data privac= y > issues, API's have the same parties with different terminology. > > 1. the subject of the data to be transferred. > > 2. the user of a grant from the subject to act as delegate. (see > https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the > user) > > 3. the site that has a repository of user data with legal obligations to > protect that data (the GDPR) (role resource server.) > > 4 the site that wants either access to the data, or some privacy > preserving statement about the existence and content of the data. (role o= f > client, vendor, PISP, etc.) > > 5. some sorts of facilitator sites for allowing access (roles like > authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been le= ft > out of OAUTH for good reason. > > > > This is a note supporting the separation of roles from legal entities. > BTW, I firmly believe that the legal entity also needs to be ID'd by the > transaction. > > Peace ..tom > > > > > > On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: > > Hi all > > > > I agree that "client" can be confusing. I would be in support of > alternative terminology. > > We can always have some wording that explains that an "Orchestrator" in > GNAP plays a similar role to "Client" in OAuth. > > > > Dave > > > > On Tue, 11 Aug 2020 at 07:52, Fabien Imbault > wrote: > > Hi Francis, > > > > I like your proposal, seems much more intuitive. > > > > Fabien > > > > Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = a =C3=A9crit : > > Hello Denis, Justin, Dick, Fabien, > > > > In this post ( > https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= ) > i suggested we use the word "Orchestrator" to designate the piece of > software that orchestrate interaction between "Requestor" (a.k.a. User), = AS > and RS to obtain the protected resource. > > > > We are turning around the same topic. As soon as we go beyond the origina= l > oAuth protocol, the word 'Client' becomes confusing. > > > > In the same response, I suggest we talk about "roles" and not "entities". > > > > Best regards. > > /Francis > > > > On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: > > I still think that client was the right name in OAuth 2, as the client > wanted to do a client-server interaction, so the client used OAuth 2 to g= et > an access token to interact with the "server". > > > > I do agree that it is not the best term in GNAP. Primarily because GNAP i= s > a combination of the client from OAuth 2, and the relying party from OIDC= . > > > > /Dick > > =E1=90=A7 > > > > On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: > > On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: > > > > The term client in OAuth came from the computer science definition of > client-server interaction. > > > > This, I would argue, is exactly why it=E2=80=99s a bad label for somethin= g that=E2=80=99s > distinctly more specific in this context, and I would love to see GNAP > adopt a more specific label for the role that we traditionally called > =E2=80=9Cclient=E2=80=9D in OAuth. > > > > =E2=80=94 Justin > > > > > > The client is getting an access token so it can call a server, > specifically, a resource server (to differentiate it from the authorizati= on > server). > > > > The confusion in my experience usually stems from people working with > software that is acting in multiple roles. IE, the software that is actin= g > as a client in once context, is also acting as an RS in other contexts, o= r > even acting as an AS. The other confusion is that people view clients as > being the software the user is using -- although it may not be acting as = a > client in the oauth context. > > > > > > > > =E1=90=A7 > > > > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault > wrote: > > Hi, > > > > To me, client has always been a strange word in the context of OAuth, as > it has a meaning well defined both in everyday life (this client is a goo= d > customer) and in computer science (client-server interaction). Thus I > always have to make the mental translation to the OAuth world before any > discussion... And any teaching experience shows that it does make the > concepts hard to grasp for a majority of (clever) people. > > > > As for the RO, previous discussions suggested Resource > Controller (RC) also, which may be a bit more specific than manager. > > > > Fabien > > > > On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: > > Justin and Dick, > > > > [Was: "Revisiting the photo sharing example (a driving use case for the > creation of OAuth)"] > > > > So let us attempt to define new terms: > > *initiating application (IA)*: application by means of which a user > initiates interactions with RS(s) and AS(s) > > In the same way, we should get rid of the term Resource Owner (RO), which > is currently defined as: > > Resource Owner (RO): entity capable of granting access to a protected > resource > > I propose to replace it with Resource Manager (RM): > > *Resource Manager (RM)* : application or user that manages an access > decision function of a Resource Server > > Denis > > > > I agree with Justin. Redefining well used terms will lead to significant > confusion. If we have a different role than what we have had in the past, > then that role should have a name not being used already in OAuth or OIDC= . > > > > Given what we have learned, and my own experience explaining what a Clien= t > is, and is not, improving the definition for Client could prove useful. I > am not suggesting the term be redefined, but clarified. > > > > For example, clarifying that a Client is a role an entity plays in the > protocol, and that the same entity may play other roles at other times, o= r > some other language to help differentiate between "role" and "entity". > > > > /Dick > > =E1=90=A7 > > > > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: > > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better= fit, but I=E2=80=99m not > really in favor of taking an existing term and applying a completely new > definition to it. In other words, I would sooner stop using =E2=80=9Cclie= nt=E2=80=9D and > come up with a new, more specific and accurate term for the role than to > define =E2=80=9Cclient=E2=80=9D as meaning something completely different= . We did this in > going from OAuth 1 to OAuth 2 already, moving from the even-more-confusin= g > =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, > nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qu= alifies it with > =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Server=E2=80= =9D. > > > > GNAP can do something similar, in my opinion. But what we can=E2=80=99t d= o is > ignore the fact that GNAP is going to be coming up in a world that is > already permeated by OAuth 2 and its terminology. We don=E2=80=99t have = a blank > slate to work with, but neither are we bound to use the same terms and > constructs as before. It=E2=80=99s going to be a delicate balance! > > > > =E2=80=94 Justin > > > > On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: > > > > I think that is fundamentally part of the question: > > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion > > > > If we say that this document assumes OAuth2.0 terminology, then we should > not change the meanings of any definition. If we are saying this supersed= es > or replaces what OAuth 2.0 creates, then we should pick the best word for > the job and ignore conflicting meanings from OAuth 2.0. I have a lot of > first hand experience of industries "ruining words", and attempting to > side-step the problem rather than redefining the word just confuses > everyone as everyone forgets the original meaning as new documents come > out, but the confusion with the use of a non-obvious word continues. > > > > Food for thought. > > - Warren > > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: > > Hi Denis, > > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > > > > Since you replied in parallel, I will make a response similar to the on= e > > I sent to Dick. > > > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in use h= ere. What > > > you describe as RS2, which might in fact be an RS unto itself, is a > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client of= RS1/. What you > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, b= ut it is not at > > > all the same as an OAuth client. I appreciate your mapping of the > > > entities below, but it makes it difficult to hold a discussion if we > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we ca= n define > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new def= initions, > > > but we=E2=80=99ve got a chance to be more precise with how we define = things. > > > > In the ISO context, each document must define its own terminology. The > > boiler plate for RFCs does not mandate a terminology or definitions > section > > but does not prevent it either. The vocabulary is limited and as long a= s > > we clearly define what our terms are meaning, we can re-use a term > already > > used in another RFC. This is also the ISO approach. > > Just because we can do something does not necessarily mean that it is a > good idea to do so. We are clear that we are producing a protocol that i= s > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted Dick = to > use the term "GS" in XAuth, picking a name that was not already used in > OAuth 2.0. > > -Ben > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > 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/ > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > > > *Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/ > . Moneyhub Financial Technology is register= ed > in England & Wales, company registration number 06909772. Moneyhub > Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Build= ing, > Temple Quay, 1 Friary, Bristol, BS1 6EA. * > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --0000000000001cab2305ac9f0a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I echo Mi= ke's comments on preserving names when possible. The shift from "c= onsumer" in OAuth 1 to "client" in OAuth 2 was confusing to = many.

I also echo Tom's comments about sep= arating Entities from Roles.

Orchestration[1] in m= y opinion is not what the "client" is doing.

=
Below is a stab at separating the entities and the roles
/Dick

Tl;dr:=C2=A0
- = Client=C2=A0-> Grant Client
- added Relying Party, Claims Issu= er, and Grant Server Operator as entities

= Roles - parties to the protocol
Grant Client (GC), Grant Serv= er (GS), Resource Server (RS)

= Entities - parties to a Trust Framework
User, Relying Party (RP), C= laims Issuer (Issuer), Grant Server Operator (GSO), Resource=C2=A0Owner (RO= )

Grant -=C2=A0may contain= claims and/or access to resources

#Protocol Ro= les

Grant Client (GC)
- used = by User
- operated / provided by RP
- requests Grants f= rom the GS
- access resources at an RS
- consumes Claim= s

Grant Server (GS)
- operated by= GSO
- may interact with the User=C2=A0
- may interact = with the RO
- accepts grant requests from GCs
- issues = grants to GCs
- may issue claims

Res= ource Server (RS)
- manages access to resources for the RO
- provides access to resources for the GC
- accepts acces= s granted by the GS

#Legal Entities

User
- uses Grant Client
- may= interact with the Grant Server
- may also be a RO
- tr= usts RP, Issuer, GSO

Relying Party (RP)
- provides Grant Client to the User.
- may trust Issuers,= GSOs, and ROs

Claims Issuer (Issuer)
=
- issues claims to RP
- may use GS or RS to issue claims

Grant Server Operator (GSO)
- operat= es the GS
- trusted by User, RP, and RO
- may also be a= n Issuer

Resource Owner (RO)
- owns resources at the RS
- trusts GSO to control access to t= he resources
- may be same entity as the User
- ma= y also be an Issuer


<= h1 id=3D"gmail-firstHeading" class=3D"gmail-firstHeading" lang=3D"en" style= =3D"color:rgb(0,0,0);margin:0px 0px 0.25em;padding:0px;overflow:visible;bor= der-bottom:1px solid rgb(162,169,177);font-size:1.8em;font-weight:normal;fo= nt-family:"Linux Libertine",Georgia,Times,serif;line-height:1.3">= Orchestration (computing)
From Wikipedia, the free encyclopedia
Jump to navigationJump = to search

In=C2=A0system administration,=C2=A0orchestration=C2=A0is the automated=C2=A0configuration, coo= rdination, and management of computer systems and=C2=A0softwa= re.<= a href=3D"https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note= -Erl-1" style=3D"text-decoration-line:none;color:rgb(11,0,128);background:n= one">[1]

A=C2=A0number of tools exist=C2=A0for automation of serv= er configuration and management, including=C2=A0Ansible,=C2= =A0Puppet,=C2=A0Salt,= =C2=A0Terraform,[2]=C2=A0and=C2=A0AWS CloudFormation.[3]

Usage[edit]

Orchestration is often discussed in the context of=C2=A0service-oriented architecture,=C2=A0virtualization,=C2=A0provisioning,=C2=A0converged infrastructure=C2=A0and dynamic=C2=A0datacenter=C2=A0topics. Orchestration in this sense is= about aligning the business request with the applications, data, and infra= structure.[4]<= /a>

In the context of=C2=A0c= loud computing, the main difference between=C2=A0workflow automation=C2=A0and orchestration is tha= t workflows are processed and completed as processes within a single domain= for automation purposes, whereas orchestration includes a workflow and pro= vides a directed action towards larger goals and objectives.[1]

In this context, and with the overall aim to ac= hieve specific goals and objectives (described through=C2=A0qua= lity of service=C2=A0parameters), for example, meet application perform= ance goals using minimized cost[5]=C2=A0and max= imize application performance within budget constraints.[6]








<= div class=3D"gmail_quote">
On Tue, Aug= 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the things= that people hated about OAuth was it invented new terminology that wasn=E2= =80=99t in common use.=C2=A0 But for better or for worse, the terms Client,= Authorization Server, and Protected Resource are now widely understood.

=C2=A0<= /u>

Let=E2=80=99s not= make people similarly hate GNAP by inventing even more novel terms, when e= xisting terms will fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choi= ce but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary menagerie wo= uld definitely make things worse.

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0<= /u>

From: TXAuth <txauth-bounces@ietf.org> On Beha= lf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match any = use case i have.

Let's be clear that there are four entities to a= single transaction in the real world sense of things. (and others that sup= port the=C2=A0 transaction.)

Then we can focus on the end point roles. I will foc= us on the data privacy issues, API's have the same parties with differe= nt terminology.

1. the subject of the data to be transferred.=

2. the user of a grant from the subject to act as de= legate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

3. the site that has a repository of user data with = legal obligations to protect that data (the GDPR) (role resource server.)

4 the site that wants either access to the data, or = some privacy preserving statement about the existence and content of the da= ta. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing acce= ss (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) these= have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of roles fr= om legal entities.=C2=A0 BTW, I firmly believe that the legal entity also n= eeds to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub= .com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would be in= support of alternative terminology.

We can always have some wording that explains that an "Orc= hestrator" in GNAP plays a similar role to "Client" in OAuth= .

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <fabien.imbault@g= mail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive.=C2= =A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Poua= tcha <fpo@adorsys.de= > a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (https://m= ailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) i sug= gested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon as we = go beyond=C2=A0the original oAuth protocol, the word 'Client' becom= es confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk about &= quot;roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the right name in OAut= h 2, as the client wanted to do a client-server interaction, so the client = used OAuth 2 to get an access token to interact with the "server"= .

=C2=A0

I do agree that it is not the best term in GNAP. Pri= marily because GNAP is a combination of the client from OAuth 2, and the re= lying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

The term client in OAuth came from the computer scie= nce definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99s a b= ad label for something that=E2=80=99s distinctly more specific in this cont= ext, and I would love to see GNAP adopt a more specific label for the role = that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can call= a server, specifically, a resource server (to differentiate it from the au= thorization server).

=C2=A0

The confusion in my experience usually stems from pe= ople working=C2=A0with software=C2=A0that is acting in multiple=C2=A0roles.= IE, the software=C2=A0that is acting as a client in once context, is also = acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@= gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in the = context of OAuth, as it has a meaning well defined both in everyday life (t= his client is a good customer) and in computer science (client-server inter= action). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested Resour= ce Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific than ma= nager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wro= te:

Justin = and Dick,

=C2=A0

[Was:= =C2=A0 "Revisiting the photo sharing example (a driving use case for t= he creation of OAuth)"]

=C2=A0

So let = us attempt to define new terms:

init= iating application (IA): application by means of which a user initiates interactions with RS(s= ) and AS(s)

In the = same way, we should get rid of the term Resource Owner (RO), which is curre= ntly defined as:

Resourc= e Owner (RO): entity capable of granting access to a protected resource

I propo= se to replace it with Resource Manager (RM):

Reso= urce Manager (RM) := application or user that manages an access decision function of a Resource= Server

Denis

=C2=A0

I agree with Justin. Redefining well used terms will= lead to significant confusion. If we have a different role than what we ha= ve had in=C2=A0the past, then that role should have a name not being used a= lready in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experience ex= plaining what a Client is, and is not, improving the definition for Client = could prove useful. I am not suggesting the term be redefined, but clarifie= d.=C2=A0

=C2=A0

For example, clarifying that a Client is a role an e= ntity plays in the protocol, and that the same entity may play other roles = at other times, or some other language to help differentiate between "= role" and "entity".

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit.edu> w= rote:

I=E2=80=99m in favor of coming up with a new term th= at=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taking an= existing term and applying a completely new definition to it. In other wor= ds, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. But wh= at we can=E2=80=99t do is ignore the fact that GNAP is going to be coming u= p in a world that is already permeated =C2=A0by OAuth 2 and its terminology= . We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wro= te:

=C2=A0

I think that is fundamentally part of the question:<= u>

We are clear that we are producing a protocol that i= s
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 termin= ology, then we should not change the meanings of any definition. If we are = saying this supersedes or replaces what OAuth 2.0 creates, then we should p= ick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warr= en Parad

Founder, CTO

Secure your user data= and complete your authorization architecture. Implement=C2=A0Authress.=

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrot= e:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

=C2=A0

=C2=A0

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology = Limited which is authorised and regulated by the Financial Conduct Authorit= y ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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

--0000000000001cab2305ac9f0a20-- From nobody Tue Aug 11 12:31:24 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 7FE463A0B2A for ; Tue, 11 Aug 2020 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GGoSFxiOKH2d for ; Tue, 11 Aug 2020 12:31:19 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564683A0ACF for ; Tue, 11 Aug 2020 12:31:19 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07BJVC0B029984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Aug 2020 15:31:13 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7064AE45-1D42-42B1-9C69-51ECDE5785CC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 11 Aug 2020 15:31:12 -0400 In-Reply-To: Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" To: Dick Hardt References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 19:31:23 -0000 --Apple-Mail=_7064AE45-1D42-42B1-9C69-51ECDE5785CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the = classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the = term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80= =9D concept that=E2=80=99s been brought up here before, so I=E2=80=99m = inclined to believe it can be a separate role from the client. I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as = it is not a =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Ccl= ient of the resource=E2=80=9D. I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything.=20 =E2=80=94 Justin > On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >=20 > I echo Mike's comments on preserving names when possible. The shift = from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >=20 > I also echo Tom's comments about separating Entities from Roles. >=20 > Orchestration[1] in my opinion is not what the "client" is doing. >=20 > Below is a stab at separating the entities and the roles >=20 > /Dick >=20 > Tl;dr:=20 > - Client -> Grant Client > - added Relying Party, Claims Issuer, and Grant Server Operator as = entities >=20 > Roles - parties to the protocol > Grant Client (GC), Grant Server (GS), Resource Server (RS) >=20 > Entities - parties to a Trust Framework > User, Relying Party (RP), Claims Issuer (Issuer), Grant Server = Operator (GSO), Resource Owner (RO) >=20 > Grant - may contain claims and/or access to resources >=20 > #Protocol Roles >=20 > Grant Client (GC) > - used by User > - operated / provided by RP > - requests Grants from the GS > - access resources at an RS > - consumes Claims >=20 > Grant Server (GS) > - operated by GSO > - may interact with the User=20 > - may interact with the RO > - accepts grant requests from GCs > - issues grants to GCs > - may issue claims >=20 > Resource Server (RS) > - manages access to resources for the RO > - provides access to resources for the GC > - accepts access granted by the GS >=20 > #Legal Entities >=20 > User > - uses Grant Client > - may interact with the Grant Server > - may also be a RO > - trusts RP, Issuer, GSO >=20 > Relying Party (RP) > - provides Grant Client to the User. > - may trust Issuers, GSOs, and ROs >=20 > Claims Issuer (Issuer) > - issues claims to RP > - may use GS or RS to issue claims >=20 > Grant Server Operator (GSO) > - operates the GS > - trusted by User, RP, and RO > - may also be an Issuer >=20 > Resource Owner (RO) > - owns resources at the RS > - trusts GSO to control access to the resources > - may be same entity as the User > - may also be an Issuer >=20 > [1] https://en.wikipedia.org/wiki/Orchestration_(computing) = >=20 > Orchestration (computing) > =46rom Wikipedia, the free encyclopedia > Jump to navigation > Jump = to search > = In = system administration = , orchestration is = the automated configuration = , coordination, = and management of computer systems and software = .[1] = > A number of tools exist = for = automation of server configuration and management, including Ansible = , Puppet = , Salt = , Terraform = ,[2] = = and AWS CloudFormation = .[3] = > Usage[edit = ] > Orchestration is often discussed in the context of service-oriented = architecture = , = virtualization , = provisioning , converged = infrastructure = and dynamic datacenter = topics. Orchestration in this sense is about aligning the business = request with the applications, data, and infrastructure.[4] = > In the context of cloud computing = , the main difference = between workflow automation = and orchestration is = that workflows are processed and completed as processes within a single = domain for automation purposes, whereas orchestration includes a = workflow and provides a directed action towards larger goals and = objectives.[1] = > In this context, and with the overall aim to achieve specific goals = and objectives (described through quality of service = parameters), for = example, meet application performance goals using minimized cost[5] = and maximize application performance within budget = constraints.[6] = >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, Aug 11, 2020 at 9:33 AM Mike Jones = > = wrote: > One of the things that people hated about OAuth was it invented new = terminology that wasn=E2=80=99t in common use. But for better or for = worse, the terms Client, Authorization Server, and Protected Resource = are now widely understood. >=20 > =20 >=20 > Let=E2=80=99s not make people similarly hate GNAP by inventing even = more novel terms, when existing terms will fit the bill. Client = wasn=E2=80=99t a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D = to the vocabulary menagerie would definitely make things worse. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: TXAuth > On Behalf Of Tom Jones > Sent: Tuesday, August 11, 2020 8:44 AM > To: Dave Tonge > > Cc: Francis Pouatcha >; Justin = Richer >; Dick Hardt = >; Benjamin Kaduk = >; Fabien Imbault = >; Denis = >; txauth@ietf.org = > Subject: Re: [GNAP] Terminology >=20 > =20 >=20 > the term "orchestator" does not match any use case i have. >=20 > Let's be clear that there are four entities to a single transaction in = the real world sense of things. (and others that support the = transaction.) >=20 > Then we can focus on the end point roles. I will focus on the data = privacy issues, API's have the same parties with different terminology. >=20 > 1. the subject of the data to be transferred. >=20 > 2. the user of a grant from the subject to act as delegate. (see = https://wiki.idesg.org/wiki/index.php/Delegation = for how to enable the = user) >=20 > 3. the site that has a repository of user data with legal obligations = to protect that data (the GDPR) (role resource server.) >=20 > 4 the site that wants either access to the data, or some privacy = preserving statement about the existence and content of the data. (role = of client, vendor, PISP, etc.) >=20 > 5. some sorts of facilitator sites for allowing access (roles like = authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left out of OAUTH for good reason. >=20 > =20 >=20 > This is a note supporting the separation of roles from legal entities. = BTW, I firmly believe that the legal entity also needs to be ID'd by = the transaction. >=20 > Peace ..tom >=20 > =20 >=20 > =20 >=20 > On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: >=20 > Hi all >=20 > =20 >=20 > I agree that "client" can be confusing. I would be in support of = alternative terminology. >=20 > We can always have some wording that explains that an "Orchestrator" = in GNAP plays a similar role to "Client" in OAuth. >=20 > =20 >=20 > Dave >=20 > =20 >=20 > On Tue, 11 Aug 2020 at 07:52, Fabien Imbault > wrote: >=20 > Hi Francis, >=20 > =20 >=20 > I like your proposal, seems much more intuitive.=20 >=20 > =20 >=20 > Fabien=20 >=20 > =20 >=20 > Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = > a =C3=A9crit : >=20 > Hello Denis, Justin, Dick, Fabien, >=20 > =20 >=20 > In this post = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ) i suggested we use the word "Orchestrator" to designate the piece of = software that orchestrate interaction between "Requestor" (a.k.a. User), = AS and RS to obtain the protected resource.=20 >=20 > =20 >=20 > We are turning around the same topic. As soon as we go beyond the = original oAuth protocol, the word 'Client' becomes confusing. >=20 > =20 >=20 > In the same response, I suggest we talk about "roles" and not = "entities". >=20 > =20 >=20 > Best regards. >=20 > /Francis >=20 > =20 >=20 > On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > wrote: >=20 > I still think that client was the right name in OAuth 2, as the client = wanted to do a client-server interaction, so the client used OAuth 2 to = get an access token to interact with the "server". >=20 > =20 >=20 > I do agree that it is not the best term in GNAP. Primarily because = GNAP is a combination of the client from OAuth 2, and the relying party = from OIDC.=20 >=20 > =20 >=20 > /Dick >=20 > =E1=90=A7 >=20 > =20 >=20 > On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > wrote: >=20 > On Aug 6, 2020, at 12:53 PM, Dick Hardt > wrote: >=20 > =20 >=20 > The term client in OAuth came from the computer science definition of = client-server interaction. >=20 > =20 >=20 > This, I would argue, is exactly why it=E2=80=99s a bad label for = something that=E2=80=99s distinctly more specific in this context, and I = would love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth. >=20 > =20 >=20 > =E2=80=94 Justin >=20 >=20 >=20 >=20 > =20 >=20 > The client is getting an access token so it can call a server, = specifically, a resource server (to differentiate it from the = authorization server). >=20 > =20 >=20 > The confusion in my experience usually stems from people working with = software that is acting in multiple roles. IE, the software that is = acting as a client in once context, is also acting as an RS in other = contexts, or even acting as an AS. The other confusion is that people = view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =E1=90=A7 >=20 > =20 >=20 > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault = > wrote: >=20 > Hi,=20 >=20 > =20 >=20 > To me, client has always been a strange word in the context of OAuth, = as it has a meaning well defined both in everyday life (this client is a = good customer) and in computer science (client-server interaction). Thus = I always have to make the mental translation to the OAuth world before = any discussion... And any teaching experience shows that it does make = the concepts hard to grasp for a majority of (clever) people. >=20 > =20 >=20 > As for the RO, previous discussions suggested Resource Controller (RC) = also, which may be a bit more specific than manager.=20 >=20 > =20 >=20 > Fabien=20 >=20 > =20 >=20 > On Thu, Aug 6, 2020 at 1:00 PM Denis > wrote: >=20 > Justin and Dick, >=20 > =20 >=20 > [Was: "Revisiting the photo sharing example (a driving use case for = the creation of OAuth)"] >=20 > =20 >=20 > So let us attempt to define new terms: >=20 > initiating application (IA): application by means of which a user = initiates interactions with RS(s) and AS(s) >=20 > In the same way, we should get rid of the term Resource Owner (RO), = which is currently defined as: >=20 > Resource Owner (RO): entity capable of granting access to a protected = resource >=20 > I propose to replace it with Resource Manager (RM): >=20 > Resource Manager (RM) : application or user that manages an access = decision function of a Resource Server >=20 > Denis >=20 > =20 >=20 > I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >=20 > =20 >=20 > Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >=20 > =20 >=20 > For example, clarifying that a Client is a role an entity plays in the = protocol, and that the same entity may play other roles at other times, = or some other language to help differentiate between "role" and = "entity". >=20 > =20 >=20 > /Dick >=20 > =E1=90=A7 >=20 > =20 >=20 > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >=20 > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >=20 > =20 >=20 > GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is ignore the fact that GNAP is going to be coming up in a world that = is already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >=20 > =20 >=20 > =E2=80=94 Justin >=20 >=20 >=20 >=20 > On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >=20 > =20 >=20 > I think that is fundamentally part of the question: >=20 > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion >=20 > =20 >=20 > If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >=20 > =20 >=20 > Food for thought. >=20 > - Warren >=20 >=20 >=20 >=20 >=20 > Warren Parad >=20 > Founder, CTO >=20 > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 > =20 >=20 > =20 >=20 > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >=20 > Hi Denis, >=20 > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > >=20 > > Since you replied in parallel, I will make a response similar to the = one=20 > > I sent to Dick. > >=20 > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 > > > you describe as RS2, which might in fact be an RS unto itself, is = a=20 > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you=20 > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 > > > all the same as an OAuth client. I appreciate your mapping of the=20= > > > entities below, but it makes it difficult to hold a discussion if = we=20 > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can define=20 > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions,=20 > > > but we=E2=80=99ve got a chance to be more precise with how we = define things. > >=20 > > In the ISO context, each document must define its own terminology. = The=20 > > boiler plate for RFCs does not mandate a terminology or definitions = section > > but does not prevent it either. The vocabulary is limited and as = long as=20 > > we clearly define what our terms are meaning, we can re-use a term = already > > used in another RFC. This is also the ISO approach. >=20 > Just because we can do something does not necessarily mean that it is = a > good idea to do so. We are clear that we are producing a protocol = that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted = Dick to > use the term "GS" in XAuth, picking a name that was not already used = in > OAuth 2.0. >=20 > -Ben >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 > =20 >=20 > -- >=20 > Francis Pouatcha >=20 > Co-Founder and Technical Lead >=20 > adorsys GmbH & Co. KG >=20 > https://adorsys-platform.de/solutions/ = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > =20 >=20 > =20 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_7064AE45-1D42-42B1-9C69-51ECDE5785CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree that =E2=80=9Corchestration=E2=80=9D is separate from what the = classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the = term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80= =9D concept that=E2=80=99s been brought up here before, so I=E2=80=99m = inclined to believe it can be a separate role from the client.

I personally think that = =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient= of the grant=E2=80=9D but rather a =E2=80=9Cclient of the = resource=E2=80=9D.

I also think it=E2=80=99s problematic to lump in user claims = with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything. 

 =E2=80=94 Justin

On Aug = 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comments on = preserving names when possible. The shift from "consumer" in OAuth 1 to = "client" in OAuth 2 was confusing to many.

I also echo Tom's = comments about separating Entities from Roles.

Orchestration[1] in my opinion is not = what the "client" is doing.

Below is a stab at separating the entities and the = roles

/Dick

Tl;dr: 
- = Client -> Grant Client
- added Relying = Party, Claims Issuer, and Grant Server Operator as entities

Roles - parties to the protocol
Grant = Client (GC), Grant Server (GS), Resource Server (RS)

Entities - parties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant = Server Operator (GSO), Resource Owner (RO)

Grant - may contain claims and/or = access to resources

#Protocol Roles

Grant Client = (GC)
- used by User
- operated = / provided by RP
- requests Grants from the = GS
- access resources at an RS
-= consumes Claims

Grant Server (GS)
- = operated by GSO
- may interact with the = User 
- may interact with the RO
- accepts grant requests from GCs
- = issues grants to GCs
- may issue claims

Resource = Server (RS)
- manages access to resources for = the RO
- provides access to resources for the = GC
- accepts access granted by the GS

#Legal = Entities

User
- uses Grant Client
- may interact with the Grant Server
- = may also be a RO
- trusts RP, Issuer, GSO

Relying = Party (RP)
- provides Grant Client to the User. =
- may trust Issuers, GSOs, and ROs

Claims = Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant Server Operator = (GSO)
- operates the GS
- = trusted by User, RP, and RO
- may also be an = Issuer

Resource Owner (RO)
- = owns resources at the RS
- trusts GSO to control = access to the resources
- may be same entity as the = User
- may also be an = Issuer

[1] https://en.wikipedia.org/wiki/Orchestration_(computing)

Orchestration (computing)

=46rom Wikipedia, the free = encyclopedia
Ju= mp to navigationJu= mp to search
In sy= stem administration, orchestration is = the automated configuration, coordination, and management of computer = systems and software.[1]
A number of tools exist for automation of server = configuration and management, including Ansible, Pu= ppet, Salt, Terraform,[2] and AW= S CloudFormation.[3]

Usage[edit]

Orchestration is often discussed = in the context of service-oriented architecture, vi= rtualization, pr= ovisioning, co= nverged infrastructure and dynamic da= tacenter topics. Orchestration in this sense is about aligning = the business request with the applications, data, and = infrastructure.[4]
In the context of cloud computing, the main difference between wo= rkflow automation and orchestration is that workflows are = processed and completed as processes within a single domain for = automation purposes, whereas orchestration includes a workflow and = provides a directed action towards larger goals and objectives.[1]
In this context, and with the overall aim to achieve specific = goals and objectives (described through quality of service parameters), for example, meet = application performance goals using minimized cost[5] and maximize application performance = within budget constraints.[6]








On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the things that people hated about OAuth was it = invented new terminology that wasn=E2=80=99t in common use.  But = for better or for worse, the terms Client, Authorization Server, and = Protected Resource are now widely understood.

 

Let=E2=80= =99s not make people similarly hate GNAP by inventing even more novel = terms, when existing terms will fit the bill.  Client wasn=E2=80=99t = a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the = vocabulary menagerie would definitely make things worse.

 

          &nb= sp;   =             &n= bsp;           &nbs= p;            =     -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

 

the term "orchestator" does not = match any use case i have.

Let's be clear that there are = four entities to a single transaction in the real world sense of things. = (and others that support the  transaction.)

Then we can focus on the end = point roles. I will focus on the data privacy issues, API's have the = same parties with different terminology.

1. the subject of the data to be = transferred.

2. the user of a grant from the = subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how = to enable the user)

3. the site that has a repository = of user data with legal obligations to protect that data (the GDPR) = (role resource server.)

4 the site that wants either = access to the data, or some privacy preserving statement about the = existence and content of the data. (role of client, vendor, PISP, = etc.)

5. some sorts of facilitator = sites for allowing access (roles like authenticator, idp, verifier, csp, = RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

 

This is a note supporting the = separation of roles from legal entities.  BTW, I firmly believe = that the legal entity also needs to be ID'd by the transaction.

Peace ..tom

 

 

On Tue, Aug 11, 2020 at 1:42 AM = Dave Tonge <dave.tonge@moneyhub.com> wrote:

Hi = all

 

I = agree that "client" can be confusing. I would be in support of = alternative terminology.

We = can always have some wording that explains that an "Orchestrator" in = GNAP plays a similar role to "Client" in OAuth.

 

Dave

 

On Tue, 11 Aug 2020 at 07:52, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Francis,

 

I like your proposal, seems much = more intuitive. 

 

Fabien 

 

Le mar. 11 ao=C3=BBt 2020 =C3=A0 = 04:17, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit :

Hello Denis, Justin, Dick, = Fabien,

 

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between = "Requestor" (a.k.a. User), AS and RS to obtain the protected = resource. 

 

We are turning around the same = topic. As soon as we go beyond the original oAuth protocol, the = word 'Client' becomes confusing.

 

In the same response, I = suggest we talk about "roles" and not "entities".

 

Best regards.

/Francis

 

On Thu, Aug 6, 2020 at 6:36 PM = Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the = right name in OAuth 2, as the client wanted to do a client-server = interaction, so the client used OAuth 2 to get an access token to = interact with the "server".

 

I do agree that it is not the = best term in GNAP. Primarily because GNAP is a combination of the client = from OAuth 2, and the relying party from OIDC. 

 

/Dick

=E1=90=A7

 

On Thu, Aug 6, 2020 at 12:50 PM = Justin Richer <jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

 

The term client in OAuth came = from the computer science definition of client-server interaction.

 

This, I would argue, is exactly = why it=E2=80=99s a bad label for something that=E2=80=99s distinctly = more specific in this context, and I would love to see GNAP adopt a more = specific label for the role that we traditionally called =E2=80=9Cclient=E2= =80=9D in OAuth.

 

 =E2=80=94 Justin



 

The client is getting an access = token so it can call a server, specifically, a resource server (to = differentiate it from the authorization server).

 

The confusion in my experience = usually stems from people working with software that is acting = in multiple roles. IE, the software that is acting as a client = in once context, is also acting as an RS in other contexts, or even = acting as an AS. The other confusion is that people view clients as being the = software the user is using -- although it may not be acting as a client = in the oauth context.

 

 

 

=E1=90=A7

 

On Thu, Aug 6, 2020 at 4:49 AM = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

 

To me, client has always been a = strange word in the context of OAuth, as it has a meaning well defined = both in everyday life (this client is a good customer) and in computer = science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And = any teaching experience shows that it does make the concepts hard to = grasp for a majority of (clever) people.

 

As for the RO, previous = discussions suggested Resource Controller (RC) also, which may = be a bit more specific than manager. 

 

Fabien 

 

On Thu, Aug 6, 2020 at 1:00 PM = Denis <denis.ietf@free.fr> wrote:

Justin and = Dick,

 

[Was:  = "Revisiting the photo sharing example (a driving use case for the = creation of OAuth)"]

 

So let us attempt to = define new terms:

initiating application = (IA): = application by means of which a user initiates interactions with RS(s) = and AS(s)

In the same way, we = should get rid of the term Resource Owner (RO), which is currently = defined as:

Resource Owner (RO): = entity capable of granting access to a protected resource

I propose to replace = it with Resource Manager (RM):

Resource Manager = (RM) = : application or user that manages an access decision function of a = Resource Server

Denis

 

I agree with Justin. Redefining = well used terms will lead to significant confusion. If we have a = different role than what we have had in the past, then that role = should have a name not being used already in OAuth or OIDC.

 

Given what we have learned, and = my own experience explaining what a Client is, and is not, improving the = definition for Client could prove useful. I am not suggesting the term = be redefined, but clarified. 

=

 

For example, clarifying that a = Client is a role an entity plays in the protocol, and that the same = entity may play other roles at other times, or some other language to = help differentiate between "role" and "entity".

 

/Dick

=E1=90=A7

 

On Wed, Aug 5, 2020 at 8:20 AM = Justin Richer <jricher@mit.edu> wrote:

I=E2=80=99m in favor of coming up = with a new term that=E2=80=99s a better fit, but I=E2=80=99m not really = in favor of taking an existing term and applying a completely new = definition to it. In other words, I would sooner stop using =E2=80=9Cclien= t=E2=80=9D and come up with a new, more specific and accurate term for the role than to define = =E2=80=9Cclient=E2=80=9D as meaning something completely different. We = did this in going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizat= ion Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

 

GNAP can do something similar, in = my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is = going to be coming up in a world that is already permeated  by = OAuth 2 and its terminology. We don=E2=80=99t have a blank slate to work = with, but neither are we bound to use the same terms and constructs as before. = It=E2=80=99s going to be a delicate balance!

 

 =E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, = Warren Parad <wparad@rhosys.ch> wrote:

 

I think that is fundamentally = part of the question:

We are clear that we are producing a protocol that = is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

 

If we say that this document = assumes OAuth2.0 terminology, then we should not change the meanings of = any definition. If we are saying this supersedes or replaces what OAuth = 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand = experience of industries "ruining words", and attempting to side-step = the problem rather than redefining the word just confuses everyone as = everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious = word continues.

 

Food for thought.

- Warren

Warren = Parad

Founder, = CTO

Secure your user data and complete your authorization = architecture. Implement Authress.

 

 

On Tue, Aug 4, 2020 at 8:53 PM = Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

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

 

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

 

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

 

--
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/

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

 

 

Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number 06909772. = Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject = to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are = made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's = business. Any opinions expressed in this email (or in any attachments) = are those of the author and do not necessarily represent the opinions of = Moneyhub Financial Technology Limited or of any other group company.


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


= --Apple-Mail=_7064AE45-1D42-42B1-9C69-51ECDE5785CC-- From nobody Tue Aug 11 12:49:54 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 2D1423A0BDE for ; Tue, 11 Aug 2020 12:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 3PVrBADjjcXn for ; Tue, 11 Aug 2020 12:49:47 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 0853E3A0BB8 for ; Tue, 11 Aug 2020 12:49:46 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id b11so7316137lfe.10 for ; Tue, 11 Aug 2020 12:49:46 -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=YRrnbu2nyOvpQBlDAHYE8Fb1I/HaucCQjQOw4sgYhes=; b=LfzxUuj+GXwxT/nH4/H8HwixTrRRnw0Ux2FNbJbsU0aJzz4TzI5oT9p48H5cEVOTM3 +NsrPUYcZFgndG4bjSYpHVV3jG6AoovfuJHHJ24XsuzLbKHYdAoKpA3f0ioTgy11dEfD rQF7J4RaVV1dDeNBkzbRwUcv+wnKnbWS/wmXznIOxGiEsfOl74pJDqgmlagHCFgxYBEL XayLV3zC0HWE0zQvync2RyuFKgpRCq6xh5WJKzfLejLU6+keGg9dZJIR8FoJM/EtbEMM IpOzOFPtyUSDMMRohdED5x614YIndv70qEUxZJGW305dfeViRRlJ7JqW4lDG887fMCJ+ 94aw== 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=YRrnbu2nyOvpQBlDAHYE8Fb1I/HaucCQjQOw4sgYhes=; b=aCPHyqxTi4ec+jmtZr59SnYWEq5u5SmqdG4coyytjQ+Dc9jcNPUFewmC4xieC3DJe5 YWjhsm0HRZflgJdF5JAw6uQ5rn6rojx7mYAM/uRVveKpq1no5wcCGCyvxTZX5M5EnthK mJeor34DyE3OdpRB4mcpnzw6REsXYW/nF1GcBS7SU/0bdwlD+hT+/Flg0XnORCwjFGiJ Ch9d+sz0vf0b7QgWT3keiiaeLMt7gnVa88AvH9KIJPYK64ar1H0aRpq2R+wDLF7TtFR4 /gtNPrUYB0zAvKV/PTF1PJGvyM5/d5QOZQ1nItm8HKm/hpSN+XI2k8qBbnzeCMgnNEQR mE2w== X-Gm-Message-State: AOAM531DaybXlwp2maAmOtP34z6MSweFhS0kclHSU4Dg3Jx503UqvJKq 1OREwU3zPXawnznw+Q78OLUdz7X4VK9bPGtd+ho= X-Google-Smtp-Source: ABdhPJxTE1Eo1jcL9HK3u931drc7Lic+QnxL1BToUSlMDhj5xzkPLTK+CJVTb1SMvbAY2AX+ee5FhufRbHfiyPylLAs= X-Received: by 2002:a19:74f:: with SMTP id 76mr3886963lfh.164.1597175384820; Tue, 11 Aug 2020 12:49:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 12:49:08 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000074d07605ac9f5f01" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 19:49:52 -0000 --00000000000074d07605ac9f5f01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that orchestrator may be a role in the protocol -- it is not a role in XYZ or XAuth today. Justin: would you explain why you think the term "grant" is problematic? It is in the WG name! The client is receiving more than access to resources from the GS, it is also receiving claims, so "client of the resource" is too limiting. Reading the definition of grant[1], it fits as a verb of what the GS is doing, and fits as a noun of what the GS provides to the client. A Grant Server is an Authorization Server in OAuth, and an OpenID Provider in OpenID Connect. The Grant Client is a Client in OAuth, and a Relying Party in OpenID Connect. Having new terms (GS and GC) in GNAP, separating the roles from OAuth and OpenID Connect. It is straightforward to know what a GC and GS do when you understand that a grant is a combination of resource access (from OAuth) and claims (from OpenID Connect). /Dick [1] https://www.dictionary.com/browse/grant verb (used with object) to bestow or confer, especially by a formal act:to grant a charter. to give or accord:to grant permission. to agree or accede to:to grant a request. to admit or concede; accept for the sake of argument:I grant that point. SEE MORE noun something granted, as a privilege or right, a sum of money, or a tract of land:Several major foundations made large grants to fund the research project. the act of granting. [1] On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote: > I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the cl= assical =E2=80=9Cclient=E2=80=9D > in OAuth is doing =E2=80=94 but the term =E2=80=9Corchestrator=E2=80=9D f= its with the =E2=80=9Cuser agent=E2=80=9D > concept that=E2=80=99s been brought up here before, so I=E2=80=99m inclin= ed to believe it > can be a separate role from the client. > > I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as it= is not a =E2=80=9Cclient > of the grant=E2=80=9D but rather a =E2=80=9Cclient of the resource=E2=80= =9D. > > I also think it=E2=80=99s problematic to lump in user claims with a =E2= =80=9Cgrant=E2=80=9D and > that=E2=80=99s just going to muddle everything. > > =E2=80=94 Justin > > On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: > > I echo Mike's comments on preserving names when possible. The shift from > "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. > > I also echo Tom's comments about separating Entities from Roles. > > Orchestration[1] in my opinion is not what the "client" is doing. > > Below is a stab at separating the entities and the roles > > /Dick > > *Tl;dr: * > - Client -> Grant Client > - added Relying Party, Claims Issuer, and Grant Server Operator as entiti= es > > *Roles* - parties to the protocol > Grant Client (GC), Grant Server (GS), Resource Server (RS) > > *Entities* - parties to a Trust Framework > User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operator > (GSO), Resource Owner (RO) > > *Grant *- may contain claims and/or access to resources > > *#Protocol Roles* > > *Grant Client* (GC) > - used by User > - operated / provided by RP > - requests Grants from the GS > - access resources at an RS > - consumes Claims > > *Grant Server* (GS) > - operated by GSO > - may interact with the User > - may interact with the RO > - accepts grant requests from GCs > - issues grants to GCs > - may issue claims > > *Resource Server* (RS) > - manages access to resources for the RO > - provides access to resources for the GC > - accepts access granted by the GS > > *#Legal Entities* > > *User* > - uses Grant Client > - may interact with the Grant Server > - may also be a RO > - trusts RP, Issuer, GSO > > *Relying Party* (RP) > - provides Grant Client to the User. > - may trust Issuers, GSOs, and ROs > > *Claims Issuer* (Issuer) > - issues claims to RP > - may use GS or RS to issue claims > > *Grant Server Operator* (GSO) > - operates the GS > - trusted by User, RP, and RO > - may also be an Issuer > > *Resource Owne*r (RO) > - owns resources at the RS > - trusts GSO to control access to the resources > - may be same entity as the User > - may also be an Issuer > > [1] https://en.wikipedia.org/wiki/Orchestration_(computing) > > Orchestration (computing) > From Wikipedia, the free encyclopedia > Jump to navigation > Jump to > search > > In system administration > , *orchestration* is > the automated configuration > , coordination, > and management of computer systems and software > .[1] > > A number of tools exist > for > automation of server configuration and management, including Ansible > , Puppet > , Salt > , Terraform > ,[2] > and= AWS > CloudFormation .[3] > > Usage[edit > > ] > Orchestration is often discussed in the context of service-oriented > architecture > , virtualization , > provisioning , converged > infrastructure a= nd > dynamic datacenter topics. > Orchestration in this sense is about aligning the business request with t= he > applications, data, and infrastructure.[4] > > In the context of cloud computing > , the main difference > between workflow automation > and orchestration is > that workflows are processed and completed as processes within a single > domain for automation purposes, whereas orchestration includes a workflow > and provides a directed action towards larger goals and objectives.[1] > > In this context, and with the overall aim to achieve specific goals and > objectives (described through quality of service > parameters), for > example, meet application performance goals using minimized cost[5] > and > maximize application performance within budget constraints.[6] > > > > > > > > > > On Tue, Aug 11, 2020 at 9:33 AM Mike Jones > wrote: > >> One of the things that people hated about OAuth was it invented new >> terminology that wasn=E2=80=99t in common use. But for better or for wo= rse, the >> terms Client, Authorization Server, and Protected Resource are now widel= y >> understood. >> >> >> >> Let=E2=80=99s not make people similarly hate GNAP by inventing even more= novel >> terms, when existing terms will fit the bill. Client wasn=E2=80=99t a p= erfect >> choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary menag= erie would >> definitely make things worse. >> >> >> >> -- Mike >> >> >> >> *From:* TXAuth *On Behalf Of *Tom Jones >> *Sent:* Tuesday, August 11, 2020 8:44 AM >> *To:* Dave Tonge >> *Cc:* Francis Pouatcha ; Justin Richer = ; >> Dick Hardt ; Benjamin Kaduk ; >> Fabien Imbault ; Denis ; >> txauth@ietf.org >> *Subject:* Re: [GNAP] Terminology >> >> >> >> the term "orchestator" does not match any use case i have. >> >> Let's be clear that there are four entities to a single transaction in >> the real world sense of things. (and others that support the transactio= n.) >> >> Then we can focus on the end point roles. I will focus on the data >> privacy issues, API's have the same parties with different terminology. >> >> 1. the subject of the data to be transferred. >> >> 2. the user of a grant from the subject to act as delegate. (see >> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the >> user) >> >> 3. the site that has a repository of user data with legal obligations to >> protect that data (the GDPR) (role resource server.) >> >> 4 the site that wants either access to the data, or some privacy >> preserving statement about the existence and content of the data. (role = of >> client, vendor, PISP, etc.) >> >> 5. some sorts of facilitator sites for allowing access (roles like >> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been l= eft >> out of OAUTH for good reason. >> >> >> >> This is a note supporting the separation of roles from legal entities. >> BTW, I firmly believe that the legal entity also needs to be ID'd by the >> transaction. >> >> Peace ..tom >> >> >> >> >> >> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >> wrote: >> >> Hi all >> >> >> >> I agree that "client" can be confusing. I would be in support of >> alternative terminology. >> >> We can always have some wording that explains that an "Orchestrator" in >> GNAP plays a similar role to "Client" in OAuth. >> >> >> >> Dave >> >> >> >> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault >> wrote: >> >> Hi Francis, >> >> >> >> I like your proposal, seems much more intuitive. >> >> >> >> Fabien >> >> >> >> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a =C3=A9crit : >> >> Hello Denis, Justin, Dick, Fabien, >> >> >> >> In this post ( >> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw= /) >> i suggested we use the word "Orchestrator" to designate the piece of >> software that orchestrate interaction between "Requestor" (a.k.a. User),= AS >> and RS to obtain the protected resource. >> >> >> >> We are turning around the same topic. As soon as we go beyond the >> original oAuth protocol, the word 'Client' becomes confusing. >> >> >> >> In the same response, I suggest we talk about "roles" and not "entities"= . >> >> >> >> Best regards. >> >> /Francis >> >> >> >> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: >> >> I still think that client was the right name in OAuth 2, as the client >> wanted to do a client-server interaction, so the client used OAuth 2 to = get >> an access token to interact with the "server". >> >> >> >> I do agree that it is not the best term in GNAP. Primarily because GNAP >> is a combination of the client from OAuth 2, and the relying party from >> OIDC. >> >> >> >> /Dick >> >> =E1=90=A7 >> >> >> >> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >> >> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >> >> >> >> The term client in OAuth came from the computer science definition of >> client-server interaction. >> >> >> >> This, I would argue, is exactly why it=E2=80=99s a bad label for somethi= ng that=E2=80=99s >> distinctly more specific in this context, and I would love to see GNAP >> adopt a more specific label for the role that we traditionally called >> =E2=80=9Cclient=E2=80=9D in OAuth. >> >> >> >> =E2=80=94 Justin >> >> >> >> >> >> The client is getting an access token so it can call a server, >> specifically, a resource server (to differentiate it from the authorizat= ion >> server). >> >> >> >> The confusion in my experience usually stems from people working with >> software that is acting in multiple roles. IE, the software that is acti= ng >> as a client in once context, is also acting as an RS in other contexts, = or >> even acting as an AS. The other confusion is that people view clients as >> being the software the user is using -- although it may not be acting as= a >> client in the oauth context. >> >> >> >> >> >> >> >> =E1=90=A7 >> >> >> >> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >> wrote: >> >> Hi, >> >> >> >> To me, client has always been a strange word in the context of OAuth, as >> it has a meaning well defined both in everyday life (this client is a go= od >> customer) and in computer science (client-server interaction). Thus I >> always have to make the mental translation to the OAuth world before any >> discussion... And any teaching experience shows that it does make the >> concepts hard to grasp for a majority of (clever) people. >> >> >> >> As for the RO, previous discussions suggested Resource >> Controller (RC) also, which may be a bit more specific than manager. >> >> >> >> Fabien >> >> >> >> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >> >> Justin and Dick, >> >> >> >> [Was: "Revisiting the photo sharing example (a driving use case for the >> creation of OAuth)"] >> >> >> >> So let us attempt to define new terms: >> >> *initiating application (IA)*: application by means of which a user >> initiates interactions with RS(s) and AS(s) >> >> In the same way, we should get rid of the term Resource Owner (RO), whic= h >> is currently defined as: >> >> Resource Owner (RO): entity capable of granting access to a protected >> resource >> >> I propose to replace it with Resource Manager (RM): >> >> *Resource Manager (RM)* : application or user that manages an access >> decision function of a Resource Server >> >> Denis >> >> >> >> I agree with Justin. Redefining well used terms will lead to significant >> confusion. If we have a different role than what we have had in the past= , >> then that role should have a name not being used already in OAuth or OID= C. >> >> >> >> Given what we have learned, and my own experience explaining what a >> Client is, and is not, improving the definition for Client could prove >> useful. I am not suggesting the term be redefined, but clarified. >> >> >> >> For example, clarifying that a Client is a role an entity plays in the >> protocol, and that the same entity may play other roles at other times, = or >> some other language to help differentiate between "role" and "entity". >> >> >> >> /Dick >> >> =E1=90=A7 >> >> >> >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >> >> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bette= r fit, but I=E2=80=99m >> not really in favor of taking an existing term and applying a completely >> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >> and come up with a new, more specific and accurate term for the role tha= n >> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diffe= rent. We did this >> in going from OAuth 1 to OAuth 2 already, moving from the >> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >> >> >> >> GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is >> ignore the fact that GNAP is going to be coming up in a world that is >> already permeated by OAuth 2 and its terminology. We don=E2=80=99t have= a blank >> slate to work with, but neither are we bound to use the same terms and >> constructs as before. It=E2=80=99s going to be a delicate balance! >> >> >> >> =E2=80=94 Justin >> >> >> >> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >> >> >> >> I think that is fundamentally part of the question: >> >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion >> >> >> >> If we say that this document assumes OAuth2.0 terminology, then we shoul= d >> not change the meanings of any definition. If we are saying this superse= des >> or replaces what OAuth 2.0 creates, then we should pick the best word fo= r >> the job and ignore conflicting meanings from OAuth 2.0. I have a lot of >> first hand experience of industries "ruining words", and attempting to >> side-step the problem rather than redefining the word just confuses >> everyone as everyone forgets the original meaning as new documents come >> out, but the confusion with the use of a non-obvious word continues. >> >> >> >> Food for thought. >> >> - Warren >> >> >> *Warren Parad* >> >> Founder, CTO >> >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> >> >> >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >> >> Hi Denis, >> >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> > >> > Since you replied in parallel, I will make a response similar to the >> one >> > I sent to Dick. >> > >> > > Hi Denis, >> > > >> > > I think there=E2=80=99s still a problem with the terminology in use = here. >> What >> > > you describe as RS2, which might in fact be an RS unto itself, is a >> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client o= f RS1/. What you >> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, = but it is not at >> > > all the same as an OAuth client. I appreciate your mapping of the >> > > entities below, but it makes it difficult to hold a discussion if we >> > > aren=E2=80=99t using the same terms. >> > > >> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we c= an define >> > > our own terms. The bad news is that this is really hard to do. >> > > >> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >> definitions, >> > > but we=E2=80=99ve got a chance to be more precise with how we define= things. >> > >> > In the ISO context, each document must define its own terminology. The >> > boiler plate for RFCs does not mandate a terminology or definitions >> section >> > but does not prevent it either. The vocabulary is limited and as long >> as >> > we clearly define what our terms are meaning, we can re-use a term >> already >> > used in another RFC. This is also the ISO approach. >> >> Just because we can do something does not necessarily mean that it is a >> good idea to do so. We are clear that we are producing a protocol that = is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion. If I understand correctly, a similar reasoning prompted Dick >> to >> use the term "GS" in XAuth, picking a name that was not already used in >> OAuth 2.0. >> >> -Ben >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> 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/ >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> >> >> *Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/ >> . Moneyhub Financial Technology is registe= red >> in England & Wales, company registration number 06909772. Moneyhub >> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buil= ding, >> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> > --00000000000074d07605ac9f5f01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that orchestrator may be a role in the protocol --= it is not a role in XYZ or XAuth today.

Justin: would y= ou explain why you think the term "grant" is problematic? It is i= n the WG name!

The client is receiving=C2=A0more t= han access to resources from the GS, it is also receiving=C2=A0claims, so &= quot;client of the resource" is too limiting.

Reading the definition of grant[1], it fits as a verb of what the GS is do= ing, and fits as a noun of what the GS provides to the client.
A Grant Server is an Authorization Server in OAuth, and an Ope= nID Provider in OpenID Connect.
The Grant Client is a Client in O= Auth, and a Relying Party in OpenID Connect.

Havin= g new terms (GS and GC) in GNAP, separating the roles from OAuth and OpenID= Connect.
It is straightforward=C2=A0to know what a GC and GS do = when you understand that=C2=A0a grant is a combination of resource access (= from OAuth) and claims (from OpenID Connect).

/Dic= k

v= erb (used with object)

= to bestow or confer, especially by a formal act:to grant a charter.
to give or accord:to grant permission.<= /span>
to agree or accede to:to grant a request.
to admit or concede; accept for th= e sake of argument:I grant that point.
<= /div>

noun

someth= ing granted, as a privilege or right, a sum of money, or a tract of land:Sever= al major foundations made large grants to fund the research project.=
the act of granting.
<= /div>


[1]=C2=A0


On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that =E2=80=9Corchestration=E2=80=9D is separate fro= m what the classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 b= ut the term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agen= t=E2=80=9D concept that=E2=80=99s been brought up here before, so I=E2=80= =99m inclined to believe it can be a separate role from the client.
I personally think that =E2=80=9Cgrant client=E2=80=9D is confu= sing as it is not a =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2= =80=9Cclient of the resource=E2=80=9D.

I also thin= k it=E2=80=99s problematic to lump in user claims with a =E2=80=9Cgrant=E2= =80=9D and that=E2=80=99s just going to muddle everything.=C2=A0
=
=C2=A0=E2=80=94 Justin

On Aug 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
<= br>
I= echo Mike's comments on preserving names when possible. The shift from= "consumer" in OAuth 1 to "client" in OAuth 2 was confu= sing to many.

I also echo Tom's comments a= bout separating Entities from Roles.

Orchestration= [1] in my opinion is not what the "client" is doing.
Below is a stab at separating the entities and the roles
=

/Dick

Tl;dr:=C2=A0
- Client=C2=A0-> Grant Client
- added Relying Party, Cla= ims Issuer, and Grant Server Operator as entities

=
Roles - parties to the protocol
Grant Client (GC), Gr= ant Server (GS), Resource Server (RS)

=
Entities - parties to a Trust Framework
User, Relying Party= (RP), Claims Issuer (Issuer), Grant Server Operator (GSO), Resource=C2=A0O= wner (RO)

Grant -=C2=A0may= contain claims and/or access to resources

#Pro= tocol Roles

Grant Client (GC)
- used by User
- operated / provided by RP
- requests = Grants from the GS
- access resources at an RS
- consum= es Claims

Grant Server (GS)
- ope= rated by GSO
- may interact with the User=C2=A0
- may i= nteract with the RO
- accepts grant requests from GCs
-= issues grants to GCs
- may issue claims

Resource Server (RS)
- manages access to resources for t= he RO
- provides access to resources for the GC
- accep= ts access granted by the GS

#Legal Entities=

User
- uses Grant Client
- may interact with the Grant Server
- may also be a RO
<= div>- trusts RP, Issuer, GSO

Relying Party = (RP)
- provides Grant Client to the User.
- may trust = Issuers, GSOs, and ROs

Claims Issuer (Issue= r)
- issues claims to RP
- may use GS or RS to issue cl= aims

Grant Server Operator (GSO)
= - operates the GS
- trusted by User, RP, and RO
- may a= lso be an Issuer

Resource Owner (RO)=
- owns resources at the RS
- trusts GSO to control acc= ess to the resources
- may be same entity as the User
<= div>- may also be an Issuer


Orchestration (computing)

From Wikipedia, the free encyclopedia
Jump to navigationJump to search
In=C2=A0<= a href=3D"https://en.wikipedia.org/wiki/System_administration" title=3D"Sys= tem administration" style=3D"text-decoration-line:none;color:rgb(11,0,128);= background:none" target=3D"_blank">system administration,=C2=A0orche= stration=C2=A0is the automated=C2=A0configuration, coordination, and management of computer systems = and=C2=A0software.[1]=
A=C2=A0number of tools exist=C2=A0for automati= on of server configuration and management, including=C2=A0Ansible,=C2=A0Puppet,=C2= =A0Salt,=C2=A0Terraform,<= a href=3D"https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note= -2" style=3D"text-decoration-line:none;color:rgb(11,0,128);background:none"= target=3D"_blank">[2]=C2=A0and=C2=A0AWS CloudFormation.[3]

U= sage[edit]

Orchestration is ofte= n discussed in the context of=C2=A0service-oriented architecture,=C2=A0virtualization,=C2=A0provisioning,=C2=A0converged infrastructure<= /a>=C2=A0and dynamic=C2=A0datacenter=C2=A0topics. Orchest= ration in this sense is about aligning the business request with the applic= ations, data, and infrastructure.[4]
In the context of=C2=A0cloud computing= , the main difference between=C2=A0work= flow automation=C2=A0and orchestration is that workflows are processed = and completed as processes within a single domain for automation purposes, = whereas orchestration includes a workflow and provides a directed action to= wards larger goals and objectives.[1]
In this context, and with the overall aim to achiev= e specific goals and objectives (described through=C2=A0quality of service=C2=A0parameters), for example, meet appl= ication performance goals using minimized cost[5]=C2=A0and maximize application performance within budge= t constraints.[6]








On Tue, Aug 11, 2020 at 9:33 = AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

=C2=A0

Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

= From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match= any use case i have.

Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would = be in support of alternative terminology.

We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive= .=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

=C2=A0

I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1= =90=A7

=C2=A0

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

The term client in OAuth came from the computer= science definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

=C2=A0

The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1= =90=A7

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

Ju= stin and Dick,

=C2=A0

[W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

=C2=A0

So= let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

Re= source Owner (RO): entity capable of granting access to a protected resourc= e

I = propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

D= enis

=C2=A0

I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

=C2=A0

For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

=C2=A0

/Dick

=E1= =90=A7

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

=C2=A0

I think that is fundamentally part of the quest= ion:

We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warren Parad<= u>

Founder, CTO=

Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

=C2=A0

=C2=A0

Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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


--00000000000074d07605ac9f5f01-- From nobody Tue Aug 11 12:54:50 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 CCC703A0C13 for ; Tue, 11 Aug 2020 12:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 bdGYAUOgw9Vf for ; Tue, 11 Aug 2020 12:54:48 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 2302A3A0C0F for ; Tue, 11 Aug 2020 12:54:48 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id c15so7338098lfi.3 for ; Tue, 11 Aug 2020 12:54:48 -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=q6JTbpCC1dgKHmLaeA4iFv9Mdbj5h+JYNwjkZqiOFms=; b=IBbtQyx5t/q9SRhb2PfAMvUPSCp9Teoydlo4q6x6i8ThWx/JBKur4Qs7Gz3VQ/WVhN bZoHMvGRBpogcLb1kjm+TPzPkMkrPky5ErsahZoEQK23GZeSdNmLOTyCi/KWT25LvFOr JacI5cv804GHjml3xmFOWmcm5tKKt0PizNNFD64djKlMCdiztYRi9ogupt7U8PPoqZTf xHvOk5J7ldewfu0VlQ++G0zpJd699iHVhNed0VeJfkeSrfsDn2ycTuoHNsO6xjL1aaak W4UQ8fDyGa/Ox9c3XZy+1MrtEKuUM7BuI0e4MZSjBkEJBAjL0Q+lihfavfkOszpwwg+e p/VQ== 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=q6JTbpCC1dgKHmLaeA4iFv9Mdbj5h+JYNwjkZqiOFms=; b=o5tXkm9REAUO1a7gjP0Vu8ZBDYH1CyS7gBa8Shk3aEaV6CkS/8qJsQGh1Di+xj4CQr K6Tc3/GkNbGe55lJunBoHcY5e9LvMerf1+XkWmjKb5gt8CvME7IhkNC2hw+cxIT1vZGb tL9wWetmAHyqINp+BfaY2CxWy/bloO8a+V2fv/vtKUc2zIUrWtQQXC+chsnb5t29uwtH BEXdjiFI7VP0VETVKVrb3gCtksgexIKHRPOHEs/NJLnOfDQXH+EmC1NowiQcr2XBvUGA MEEqXKJNpp5KEhtKrU6okub8Kl8+AI6y4lKZNZ/39Otm3rgCKN5deRmUQU1Cs0/S3LC5 p3dg== X-Gm-Message-State: AOAM532mGFJHbuN/liI1pcJbskoSqkpSCmLRWMMXRPM+8gGroE3aY/Co YqDY7dfNgZvB+TpQpivCfk/e92bZQrJi84sKOvo= X-Google-Smtp-Source: ABdhPJxjvvrGEe/+Xaqxzf9qYkZ4mx1cpWKh914Ngs1YUlhwuFgXdspiKEb7d0i0PhdfXYGMs+T2HBw6ubLA4hAty8c= X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr3909718lfp.23.1597175686137; Tue, 11 Aug 2020 12:54:46 -0700 (PDT) MIME-Version: 1.0 References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 12:54:10 -0700 Message-ID: To: Mike Jones Cc: Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006a8d1d05ac9f717b" Archived-At: Subject: Re: [GNAP] Design team formed 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, 11 Aug 2020 19:54:50 -0000 --0000000000006a8d1d05ac9f717b Content-Type: text/plain; charset="UTF-8" Mike: I'm going to add in the updated terms I just posted to the list to the XAuth ID later today. On Tue, Aug 11, 2020 at 10:02 AM Dick Hardt wrote: > Leif / Yaron: thanks for organizing! > > Kathleen, Mike, Fabien: thanks for stepping up. > > Mike: I have a number of adjustments I had queued for a new version prior > to the WG meeting, but I did not think it was useful to push new concepts > or material given the path to have a design team. > > > On Tue, Aug 11, 2020 at 9:14 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >> Thanks for your confidence in me and the rest of the design team. I plan >> to read both individual specs cover-to-cover as part of my preparation for >> this work. >> >> Dick and Justin, are there additional edits you plan to publish before I >> should do my review, or should I review the currently published drafts? >> >> Thanks, >> -- Mike >> >> -----Original Message----- >> From: TXAuth On Behalf Of Yaron Sheffer >> Sent: Tuesday, August 11, 2020 3:43 AM >> To: GNAP Mailing List >> Subject: [GNAP] Design team formed >> >> Thank you all for attending the inaugural GNAP meeting at IETF-108. We >> had quite a few volunteers, and the chairs picked the following people for >> the design team: >> >> * Kathleen Moriarty >> * Justin Richer >> * Dick Hardt >> * Mike Jones >> * Fabien Imbault >> >> Kathleen has graciously agreed to convene the sessions and report on the >> team's outcome. Thank you all who volunteered! >> >> We expect the design team to decide on a solution outline that combines >> the best of both proposals, and present this outline by Sep. 15. Anything >> is as usual subject to approval by the whole working group. >> >> Thanks, >> Leif and Yaron >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000006a8d1d05ac9f717b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike: I'm going to add in the updated terms I just pos= ted to the list to the XAuth ID later today.

On Tue, Aug 11, 2020 at 10:02 A= M Dick Hardt <dick.hardt@gmail.c= om> wrote:
Leif / Yaron: thanks for organizing!

= Kathleen, Mike, Fabien: thanks for stepping up.

Mi= ke: I have a number of adjustments I had queued for a new version prior to = the WG meeting, but I did not think it was useful to push new concepts or m= aterial given=C2=A0the path to have a design team.=C2=A0


On Tue, Aug 11, 2020 at 9:14 AM Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
Thanks for your confidence in me and the rest of the design te= am.=C2=A0 I plan to read both individual specs cover-to-cover as part of my= preparation for this work.

Dick and Justin, are there additional edits you plan to publish before I sh= ould do my review, or should I review the currently published drafts?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent: Tuesday, August 11, 2020 3:43 AM
To: GNAP Mailing List <txauth@ietf.org>
Subject: [GNAP] Design team formed

Thank you all for attending the inaugural GNAP meeting at IETF-108. We had = quite a few volunteers, and the chairs picked the following people for the = design team:

* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron



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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000006a8d1d05ac9f717b-- From nobody Tue Aug 11 13:11:24 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 720063A0C48 for ; Tue, 11 Aug 2020 13:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 vMx1Lzz_E80U for ; Tue, 11 Aug 2020 13:11:18 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640096.outbound.protection.outlook.com [40.107.64.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B9D3A0C4D for ; Tue, 11 Aug 2020 13:11:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R9ruKupz3gz479nZFoya41Dv2YcnvNOYF8W8rzqsWMO/L9yLU+KgHWa/L8kClplX3M8hZjV6/owxJQgW79T5bLe9yZ0YBVHcWHzrs+8hX0Es92o4bHfH5cnrekEVQa8rAuTuvqfXwA5LZPKlUizKq9Gl/eYGEyBL5q5AjwN7Gi3J46kO5j2jSjSGG9hmTkZ0fR7BqI9ofWgiTMmy1hBKSTQjpTCuaP/ea23oi0kM4QzlhoohQOAFVS96PQ9fAUjzftzHkKJrkR+IWwDUPU/pcweHJQITJo1IQJLTCsG2SyFbQT+S99U4Bh4m+lVyD/qxomEomURurAoT+/NRsJnDgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Feoc9N1k6wBQM7g7BEEmOyUjFtZv/cIdsX0k4L3mTPA=; b=I/4dejYX2FRDH6XOUvyKgJvFnXHeV10xxu/10C72p0XbdNRP3CkJU1CYPkJoJNA8m68f7R+AHGm34/RRNcl6CRmituPXiCq3s9ZSF3bKkN8PJ/pdexgr6OU0C0+rjySNN37J8xaK0ZvrZg2So+KDBL6lPsOLq+VRZYh1tTUQKrMC3W+VEY3jIC1MNXD4wmFOV7cZ2Tf8elbiFn7jjYSrkhNicS2NiEDmhXkPXNI4F6GBTwrxdpoD4J6isDuSA5vvFDMR8Ol06Kl/xuoYiAt94iXYFl1V5q/eR24jIb6qyTgLcHKyjIjXFpCKbXZvg94XfRfoouiUY5kwC1Dk1V7OYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Feoc9N1k6wBQM7g7BEEmOyUjFtZv/cIdsX0k4L3mTPA=; b=XTJklOMgHP9ZqrRdVD1IViB8PZoOmqQIVRzXCoLUsaaPttYdS6Uua3mUazcfmFVBvBaqPxfxK6Ab4iZ8QKXQaqqH8rLTm/Mogt6o/hdmlg7cK+S9UJt1hmyWSg5m++BDraLG6onDRxG6LT8fXg/II0zYaL6BCLWiKuhe9Guj5a8= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0732.namprd00.prod.outlook.com (2603:10b6:5:21c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3321.0; Tue, 11 Aug 2020 20:11:15 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::d453:df4b:be59:8bd]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::d453:df4b:be59:8bd%3]) with mapi id 15.20.3321.000; Tue, 11 Aug 2020 20:11:15 +0000 From: Mike Jones To: Dick Hardt CC: Yaron Sheffer , GNAP Mailing List Thread-Topic: [GNAP] Design team formed Thread-Index: AdZwG447zNiD0UPKS0Og0KtY64t4Jg== Date: Tue, 11 Aug 2020 20:11:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-11T20:09:26Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cd2f847f-87d6-4bbe-9fec-002a3a9b6852; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.88.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6caeb21f-efac-4ac1-593e-08d83e32b37f x-ms-traffictypediagnostic: DM6PR00MB0732: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OzF4KW/kJFN6ame2UgTN7603kebiZNgB8xlTvI6jbhNnT+E3CmmwsEIqQ9wIYJDUg6rc49K7p2lQ7RxZKGF3eIaq7tBof+ZoIdJUr9TA6QIxqaHNZiW5CJD28lTt+2EfUh+5Y3MHMK7YhSFQKC91tQa47nALIieOvK3SEApHvNSehQydtFV4hUNrbR/KwIAEffiak79kTZLPj9mkn5i71p/SBqcxDz/rrOWO7Rwh5BkqFsF71Vw0/+QsMnF+9gguNnbkusmswKspAnfsW23aHcw2xNVsZMdW5DQW0ix+pY0s0QFFOQ2dLibn3zsPbrACQIa4Ns31u0wzfFX+d28eGl0dMeea7C6/paHoGc5oObS6bI8VBe1GQu8rCVt0P9jKwAD11PRErtLxAa1vVOnLrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(346002)(366004)(136003)(39860400002)(55016002)(33656002)(9686003)(478600001)(10290500003)(8990500004)(7696005)(83380400001)(86362001)(966005)(5660300002)(166002)(76116006)(66946007)(4326008)(54906003)(53546011)(2906002)(316002)(64756008)(66446008)(66556008)(66476007)(71200400001)(6916009)(8936002)(82950400001)(82960400001)(52536014)(26005)(186003)(6506007)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0ZBxy1JBdVpKi2m+Dlfhk8bHxvjMXbQQvZPP14KJds/Rn1PZOFUiJjG5ZVQT90WNZq2/NFG7GG7knC7NKVTdS9c5NlrQlXPzJCKW7bXlV0MJt0sx/3TEHN4QCnpWaVqB+YBl/dA4W9bqjzSFzfTNPOaUJB8LOL+2JBIiOE4uNWWhu8OuXQFZ67mRGkgDdD2lhTlxbcb3ssPypb/4aNSz4hTAotDRPbfneX8SgMXc5Dbxt7el3ncvoBGANSTWMEJmkdDmIkON1edpGlwzBxcmCJmwgU7ceTxpyit6UZcpM80xq/70vUhG4vtC61RgmMMyPImaWlsfJBS5rd52hczuRSYc0jFqwdmkqz/aJRzhXXRCehE9EwZrFregLJjDQhmZJ4HlujGmRaW9vXIqawb8LZuYKqLCVQWoETsE/XlK9h8J+Epa8iW+naLIywStHzj5JV3t4jxR5fTFjHLeZcvByR7TNg23gc7FXN32DbJ9/Gvjr5bGApP1UamX8O9yEiqA4i8LyFeUYhoIdre8DLcQXa6WDQTHLTuQeOf8wW8/ez4jFA/bAiSBbxX/r1D7z7THgaXgyYdVmUhH4kp3VFzvRZhg9WCS4rI0OtdT/P5CYHnhcAYIs4NwkHL5HQEmRB/RrIwbQJSpIiYBIPrRov1VzQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06842CA12514736948F9F8A5F5451DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6caeb21f-efac-4ac1-593e-08d83e32b37f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 20:11:15.3022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O3EgD/zHBiyhVYL3Mc8zV3pw1RqEWF0W3yPrnQOuqM5bkuPLomJK3Iio6qffLBTj4XeN73VXWh/weDr0RRMlNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0732 Archived-At: Subject: Re: [GNAP] Design team formed 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, 11 Aug 2020 20:11:22 -0000 --_000_DM6PR00MB06842CA12514736948F9F8A5F5451DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBsZXR0aW5nIG1lIGtub3cuICBJ4oCZbGwgd2FpdCB0byBwcmludCB0aGUgY29w aWVzIEnigJltIGdvaW5nIHRvIHJldmlldyB1bnRpbCBJIHNlZSB0aGF0IHRoZSBuZXcgdmVyc2lv biBoYXMgYmVlbiBwdWJsaXNoZWQuICAoSSBhbHdheXMgZG8gbXkgYmVzdCBjb3Zlci10by1jb3Zl ciBzcGVjIHJldmlld3MgYnkgcmVhZGluZyB0aGVtIG9uIHBhcGVyIOKAkyBwcmVmZXJhYmx5IG91 dHNpZGUgaW4gbmljZSB3ZWF0aGVyLCBhd2F5IGZyb20gb3RoZXIgZGlzdHJhY3Rpb25zLikNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogVFhBdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIERpY2sgSGFyZHQNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxMSwgMjAyMCAxMjo1NCBQTQ0K VG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IEdOQVAgTWFp bGluZyBMaXN0IDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbR05BUF0gRGVzaWduIHRlYW0g Zm9ybWVkDQoNCk1pa2U6IEknbSBnb2luZyB0byBhZGQgaW4gdGhlIHVwZGF0ZWQgdGVybXMgSSBq dXN0IHBvc3RlZCB0byB0aGUgbGlzdCB0byB0aGUgWEF1dGggSUQgbGF0ZXIgdG9kYXkuDQoNCk9u IFR1ZSwgQXVnIDExLCAyMDIwIGF0IDEwOjAyIEFNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21h aWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KTGVpZiAvIFlhcm9u OiB0aGFua3MgZm9yIG9yZ2FuaXppbmchDQoNCkthdGhsZWVuLCBNaWtlLCBGYWJpZW46IHRoYW5r cyBmb3Igc3RlcHBpbmcgdXAuDQoNCk1pa2U6IEkgaGF2ZSBhIG51bWJlciBvZiBhZGp1c3RtZW50 cyBJIGhhZCBxdWV1ZWQgZm9yIGEgbmV3IHZlcnNpb24gcHJpb3IgdG8gdGhlIFdHIG1lZXRpbmcs IGJ1dCBJIGRpZCBub3QgdGhpbmsgaXQgd2FzIHVzZWZ1bCB0byBwdXNoIG5ldyBjb25jZXB0cyBv ciBtYXRlcmlhbCBnaXZlbiB0aGUgcGF0aCB0byBoYXZlIGEgZGVzaWduIHRlYW0uDQoNCg0KT24g VHVlLCBBdWcgMTEsIDIwMjAgYXQgOToxNCBBTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJj LmlldGYub3JnPj4gd3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgY29uZmlkZW5jZSBpbiBtZSBhbmQg dGhlIHJlc3Qgb2YgdGhlIGRlc2lnbiB0ZWFtLiAgSSBwbGFuIHRvIHJlYWQgYm90aCBpbmRpdmlk dWFsIHNwZWNzIGNvdmVyLXRvLWNvdmVyIGFzIHBhcnQgb2YgbXkgcHJlcGFyYXRpb24gZm9yIHRo aXMgd29yay4NCg0KRGljayBhbmQgSnVzdGluLCBhcmUgdGhlcmUgYWRkaXRpb25hbCBlZGl0cyB5 b3UgcGxhbiB0byBwdWJsaXNoIGJlZm9yZSBJIHNob3VsZCBkbyBteSByZXZpZXcsIG9yIHNob3Vs ZCBJIHJldmlldyB0aGUgY3VycmVudGx5IHB1Ymxpc2hlZCBkcmFmdHM/DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUWEF1dGgg PHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiBZYXJvbiBTaGVmZmVyDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTEsIDIw MjAgMzo0MyBBTQ0KVG86IEdOQVAgTWFpbGluZyBMaXN0IDx0eGF1dGhAaWV0Zi5vcmc8bWFpbHRv OnR4YXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbR05BUF0gRGVzaWduIHRlYW0gZm9ybWVkDQoN ClRoYW5rIHlvdSBhbGwgZm9yIGF0dGVuZGluZyB0aGUgaW5hdWd1cmFsIEdOQVAgbWVldGluZyBh dCBJRVRGLTEwOC4gV2UgaGFkIHF1aXRlIGEgZmV3IHZvbHVudGVlcnMsIGFuZCB0aGUgY2hhaXJz IHBpY2tlZCB0aGUgZm9sbG93aW5nIHBlb3BsZSBmb3IgdGhlIGRlc2lnbiB0ZWFtOg0KDQoqIEth dGhsZWVuIE1vcmlhcnR5DQoqIEp1c3RpbiBSaWNoZXINCiogRGljayBIYXJkdA0KKiBNaWtlIEpv bmVzDQoqIEZhYmllbiBJbWJhdWx0DQoNCkthdGhsZWVuIGhhcyBncmFjaW91c2x5IGFncmVlZCB0 byBjb252ZW5lIHRoZSBzZXNzaW9ucyBhbmQgcmVwb3J0IG9uIHRoZSB0ZWFtJ3Mgb3V0Y29tZS4g VGhhbmsgeW91IGFsbCB3aG8gdm9sdW50ZWVyZWQhDQoNCldlIGV4cGVjdCB0aGUgZGVzaWduIHRl YW0gdG8gZGVjaWRlIG9uIGEgc29sdXRpb24gb3V0bGluZSB0aGF0IGNvbWJpbmVzIHRoZSBiZXN0 IG9mIGJvdGggcHJvcG9zYWxzLCBhbmQgcHJlc2VudCB0aGlzIG91dGxpbmUgYnkgU2VwLiAxNS4g QW55dGhpbmcgaXMgYXMgdXN1YWwgc3ViamVjdCB0byBhcHByb3ZhbCBieSB0aGUgd2hvbGUgd29y a2luZyBncm91cC4NCg0KVGhhbmtzLA0KICAgICAgICBMZWlmIGFuZCBZYXJvbg0KDQoNCg0KLS0N ClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KLS0N ClRYQXV0aCBtYWlsaW5nIGxpc3QNClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg== --_000_DM6PR00MB06842CA12514736948F9F8A5F5451DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAy MDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPlRoYW5rcyBmb3IgbGV0dGluZyBtZSBrbm93LiZuYnNwOyBJ4oCZbGwgd2FpdCB0byBwcmlu dCB0aGUgY29waWVzIEnigJltIGdvaW5nIHRvIHJldmlldyB1bnRpbCBJIHNlZSB0aGF0IHRoZSBu ZXcgdmVyc2lvbiBoYXMgYmVlbiBwdWJsaXNoZWQuJm5ic3A7IChJIGFsd2F5cyBkbyBteSBiZXN0 IGNvdmVyLXRvLWNvdmVyIHNwZWMgcmV2aWV3cyBieSByZWFkaW5nIHRoZW0gb24gcGFwZXIg4oCT DQogcHJlZmVyYWJseSBvdXRzaWRlIGluIG5pY2Ugd2VhdGhlciwgYXdheSBmcm9tIG90aGVyIGRp c3RyYWN0aW9ucy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVFhBdXRoICZsdDt0eGF1dGgtYm91bmNl c0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+RGljayBIYXJkdDxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTEsIDIwMjAgMTI6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gWWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21h aWwuY29tJmd0OzsgR05BUCBNYWlsaW5nIExpc3QgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW0dOQVBdIERlc2lnbiB0ZWFtIGZvcm1lZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlOiBJJ20gZ29pbmcgdG8gYWRkIGluIHRoZSB1 cGRhdGVkIHRlcm1zIEkganVzdCBwb3N0ZWQgdG8gdGhlIGxpc3QgdG8gdGhlIFhBdXRoIElEIGxh dGVyIHRvZGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBBdWcgMTEsIDIwMjAgYXQgMTA6MDIgQU0gRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkxlaWYgLyBZYXJvbjogdGhhbmtzIGZvciBvcmdhbml6aW5nITxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0aGxlZW4sIE1pa2Us IEZhYmllbjogdGhhbmtzIGZvciBzdGVwcGluZyB1cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZTogSSBoYXZlIGEgbnVtYmVyIG9mIGFk anVzdG1lbnRzIEkgaGFkIHF1ZXVlZCBmb3IgYSBuZXcgdmVyc2lvbiBwcmlvciB0byB0aGUgV0cg bWVldGluZywgYnV0IEkgZGlkIG5vdCB0aGluayBpdCB3YXMgdXNlZnVsIHRvIHB1c2ggbmV3IGNv bmNlcHRzIG9yIG1hdGVyaWFsIGdpdmVuJm5ic3A7dGhlIHBhdGggdG8gaGF2ZSBhIGRlc2lnbiB0 ZWFtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDExLCAyMDIwIGF0IDk6MTQgQU0gTWlrZSBKb25lcyAmbHQ7 TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgY29uZmlkZW5jZSBpbiBtZSBhbmQgdGhlIHJlc3Qg b2YgdGhlIGRlc2lnbiB0ZWFtLiZuYnNwOyBJIHBsYW4gdG8gcmVhZCBib3RoIGluZGl2aWR1YWwg c3BlY3MgY292ZXItdG8tY292ZXIgYXMgcGFydCBvZiBteSBwcmVwYXJhdGlvbiBmb3IgdGhpcyB3 b3JrLjxicj4NCjxicj4NCkRpY2sgYW5kIEp1c3RpbiwgYXJlIHRoZXJlIGFkZGl0aW9uYWwgZWRp dHMgeW91IHBsYW4gdG8gcHVibGlzaCBiZWZvcmUgSSBzaG91bGQgZG8gbXkgcmV2aWV3LCBvciBz aG91bGQgSSByZXZpZXcgdGhlIGN1cnJlbnRseSBwdWJsaXNoZWQgZHJhZnRzPzxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBU aGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IC0tIE1pa2U8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206IFRYQXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBC ZWhhbGYgT2YgWWFyb24gU2hlZmZlcjxicj4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxMSwgMjAy MCAzOjQzIEFNPGJyPg0KVG86IEdOQVAgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86 dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZndDs8 YnI+DQpTdWJqZWN0OiBbR05BUF0gRGVzaWduIHRlYW0gZm9ybWVkPGJyPg0KPGJyPg0KVGhhbmsg eW91IGFsbCBmb3IgYXR0ZW5kaW5nIHRoZSBpbmF1Z3VyYWwgR05BUCBtZWV0aW5nIGF0IElFVEYt MTA4LiBXZSBoYWQgcXVpdGUgYSBmZXcgdm9sdW50ZWVycywgYW5kIHRoZSBjaGFpcnMgcGlja2Vk IHRoZSBmb2xsb3dpbmcgcGVvcGxlIGZvciB0aGUgZGVzaWduIHRlYW06PGJyPg0KPGJyPg0KKiBL YXRobGVlbiBNb3JpYXJ0eTxicj4NCiogSnVzdGluIFJpY2hlcjxicj4NCiogRGljayBIYXJkdDxi cj4NCiogTWlrZSBKb25lczxicj4NCiogRmFiaWVuIEltYmF1bHQ8YnI+DQo8YnI+DQpLYXRobGVl biBoYXMgZ3JhY2lvdXNseSBhZ3JlZWQgdG8gY29udmVuZSB0aGUgc2Vzc2lvbnMgYW5kIHJlcG9y dCBvbiB0aGUgdGVhbSdzIG91dGNvbWUuIFRoYW5rIHlvdSBhbGwgd2hvIHZvbHVudGVlcmVkITxi cj4NCjxicj4NCldlIGV4cGVjdCB0aGUgZGVzaWduIHRlYW0gdG8gZGVjaWRlIG9uIGEgc29sdXRp b24gb3V0bGluZSB0aGF0IGNvbWJpbmVzIHRoZSBiZXN0IG9mIGJvdGggcHJvcG9zYWxzLCBhbmQg cHJlc2VudCB0aGlzIG91dGxpbmUgYnkgU2VwLiAxNS4gQW55dGhpbmcgaXMgYXMgdXN1YWwgc3Vi amVjdCB0byBhcHByb3ZhbCBieSB0aGUgd2hvbGUgd29ya2luZyBncm91cC48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExlaWYgYW5kIFlhcm9uPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KVFhBdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UWEF1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aDwvYT48YnI+DQo8YnI+DQotLSA8YnI+DQpUWEF1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRYQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PlRYQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DM6PR00MB06842CA12514736948F9F8A5F5451DM6PR00MB0684namp_-- From nobody Tue Aug 11 13:31:30 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 0AA0C3A0CA4 for ; Tue, 11 Aug 2020 13:31:29 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (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 7wnp8dIo_qgJ for ; Tue, 11 Aug 2020 13:31:24 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 DB85C3A0CA2 for ; Tue, 11 Aug 2020 13:31:23 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id k20so4086267wmi.5 for ; Tue, 11 Aug 2020 13:31:23 -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=nG3h+XPwosou+UZ4tPyfjDRiBMPb+aWxICKgqOxlSeA=; b=ag4kzkwmuVgq7DTBbWzl3l3oxauUytgvrUvDIhGtrQ+duMuqo0MGA7HeCLuyi511Ou YzmrcKvKUNWoO0zJvFr/tO4eCvJhsU/vx3BccNLlauKv5H2O7azhzEZqaxjiHnWdgODs JCvaBVWAQGg2515XU5kjiTeY+YTi+H8tUa7lg= 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=nG3h+XPwosou+UZ4tPyfjDRiBMPb+aWxICKgqOxlSeA=; b=qcgnNbTyBNz4Qf2IquxEo5nCg6/AfDUwSnR/8Uo1JyMIgipfaWwQxL1CzoWKC8+2tG Y2zOTU8LKEXKp4To1KB3Wf4HPdrp8SeRJR9Y4OpzYUeS3lf8bmS83A2Bk4mtXQS42Nbq 8fRDHgHuXTcS2vnCVGPm6UwK3YJlF+QMn51jFuUEzpeFWlz47LKVY2zLg3W9g1Gla+wv k3QEQTmLnjpZR4A6pIcTbZIgfhuc+0YfR1bMva1oD9mV4REAjh44aMwZ2v0DOt1wWCT5 Y9yho+y09tEVx0C6J3+p+6954fxLv0raMmUEFGxKl28hOz98esKihKy/JhzOMB4CTTnQ 2ICQ== X-Gm-Message-State: AOAM530jpIuglqV/3+yB3+CSC8pNIwy4/KrDk04rf3jS5ATPz2tWcR+r dEDtvIoKhllhki0QtOHtDMq2BweQD6NZO7LRMfCFtQ== X-Google-Smtp-Source: ABdhPJxbHJankUQWus7DeAVfWbb41ilxUwYn7QjGCNS5Ot0MbfdyxrQZffWWmB7gV+Ya9yyOEHs2ExU1wTHKb8vlXPo= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr5187685wml.38.1597177881144; Tue, 11 Aug 2020 13:31:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 16:31:10 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , Mike Jones , Tom Jones , Dave Tonge , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003fc91805ac9ff41d" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 20:31:29 -0000 --0000000000003fc91805ac9ff41d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In GNAP the "Grant Client" is orchestrating/negotiating a grant on behalf of the Requestor. He is not the "Client" of the "Grant". The real client is the Requestor. We can assign this client the role of a "Negotiator" (if the word "Orchestrator" does not fit). Best regards /Francis On Tue, Aug 11, 2020 at 3:49 PM Dick Hardt wrote: > I agree that orchestrator may be a role in the protocol -- it is not a > role in XYZ or XAuth today. > > Justin: would you explain why you think the term "grant" is problematic? > It is in the WG name! > > The client is receiving more than access to resources from the GS, it is > also receiving claims, so "client of the resource" is too limiting. > > Reading the definition of grant[1], it fits as a verb of what the GS is > doing, and fits as a noun of what the GS provides to the client. > > A Grant Server is an Authorization Server in OAuth, and an OpenID Provide= r > in OpenID Connect. > The Grant Client is a Client in OAuth, and a Relying Party in OpenID > Connect. > > Having new terms (GS and GC) in GNAP, separating the roles from OAuth and > OpenID Connect. > It is straightforward to know what a GC and GS do when you understand > that a grant is a combination of resource access (from OAuth) and claims > (from OpenID Connect). > > /Dick > > [1] https://www.dictionary.com/browse/grant > verb (used with object) > to bestow or confer, especially by a formal act:to grant a charter. > to give or accord:to grant permission. > to agree or accede to:to grant a request. > to admit or concede; accept for the sake of argument:I grant that point. > SEE MORE > noun > something granted, as a privilege or right, a sum of money, or a tract of > land:Several major foundations made large grants to fund the research > project. > the act of granting. > > > [1] > > > > On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote: > >> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the c= lassical =E2=80=9Cclient=E2=80=9D >> in OAuth is doing =E2=80=94 but the term =E2=80=9Corchestrator=E2=80=9D = fits with the =E2=80=9Cuser agent=E2=80=9D >> concept that=E2=80=99s been brought up here before, so I=E2=80=99m incli= ned to believe it >> can be a separate role from the client. >> >> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as i= t is not a >> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of th= e resource=E2=80=9D. >> >> I also think it=E2=80=99s problematic to lump in user claims with a =E2= =80=9Cgrant=E2=80=9D and >> that=E2=80=99s just going to muddle everything. >> >> =E2=80=94 Justin >> >> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >> >> I echo Mike's comments on preserving names when possible. The shift from >> "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >> >> I also echo Tom's comments about separating Entities from Roles. >> >> Orchestration[1] in my opinion is not what the "client" is doing. >> >> Below is a stab at separating the entities and the roles >> >> /Dick >> >> *Tl;dr: * >> - Client -> Grant Client >> - added Relying Party, Claims Issuer, and Grant Server Operator as >> entities >> >> *Roles* - parties to the protocol >> Grant Client (GC), Grant Server (GS), Resource Server (RS) >> >> *Entities* - parties to a Trust Framework >> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operator >> (GSO), Resource Owner (RO) >> >> *Grant *- may contain claims and/or access to resources >> >> *#Protocol Roles* >> >> *Grant Client* (GC) >> - used by User >> - operated / provided by RP >> - requests Grants from the GS >> - access resources at an RS >> - consumes Claims >> >> *Grant Server* (GS) >> - operated by GSO >> - may interact with the User >> - may interact with the RO >> - accepts grant requests from GCs >> - issues grants to GCs >> - may issue claims >> >> *Resource Server* (RS) >> - manages access to resources for the RO >> - provides access to resources for the GC >> - accepts access granted by the GS >> >> *#Legal Entities* >> >> *User* >> - uses Grant Client >> - may interact with the Grant Server >> - may also be a RO >> - trusts RP, Issuer, GSO >> >> *Relying Party* (RP) >> - provides Grant Client to the User. >> - may trust Issuers, GSOs, and ROs >> >> *Claims Issuer* (Issuer) >> - issues claims to RP >> - may use GS or RS to issue claims >> >> *Grant Server Operator* (GSO) >> - operates the GS >> - trusted by User, RP, and RO >> - may also be an Issuer >> >> *Resource Owne*r (RO) >> - owns resources at the RS >> - trusts GSO to control access to the resources >> - may be same entity as the User >> - may also be an Issuer >> >> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >> >> Orchestration (computing) >> From Wikipedia, the free encyclopedia >> Jump to navigation >> Jump to >> search >> >> In system administration >> , *orchestration* i= s >> the automated configuration >> , coordination, >> and management of computer systems and software >> .[1] >> >> A number of tools exist >> for >> automation of server configuration and management, including Ansible >> , Puppet >> , Salt >> , Terraform >> ,[2] >> >> and AWS CloudFormation >> .[3] >> >> Usage[edit >> >> ] >> Orchestration is often discussed in the context of service-oriented >> architecture >> , >> virtualization , >> provisioning , converged >> infrastructure = and >> dynamic datacenter topics. >> Orchestration in this sense is about aligning the business request with = the >> applications, data, and infrastructure.[4] >> >> In the context of cloud computing >> , the main difference >> between workflow automation >> and orchestration is >> that workflows are processed and completed as processes within a single >> domain for automation purposes, whereas orchestration includes a workflo= w >> and provides a directed action towards larger goals and objectives.[1] >> >> In this context, and with the overall aim to achieve specific goals and >> objectives (described through quality of service >> parameters), for >> example, meet application performance goals using minimized cost[5] >> and >> maximize application performance within budget constraints.[6] >> >> >> >> >> >> >> >> >> >> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones >> wrote: >> >>> One of the things that people hated about OAuth was it invented new >>> terminology that wasn=E2=80=99t in common use. But for better or for w= orse, the >>> terms Client, Authorization Server, and Protected Resource are now wide= ly >>> understood. >>> >>> >>> >>> Let=E2=80=99s not make people similarly hate GNAP by inventing even mor= e novel >>> terms, when existing terms will fit the bill. Client wasn=E2=80=99t a = perfect >>> choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary mena= gerie would >>> definitely make things worse. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* TXAuth *On Behalf Of *Tom Jones >>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>> *To:* Dave Tonge >>> *Cc:* Francis Pouatcha ; Justin Richer ; >>> Dick Hardt ; Benjamin Kaduk ; >>> Fabien Imbault ; Denis ; >>> txauth@ietf.org >>> *Subject:* Re: [GNAP] Terminology >>> >>> >>> >>> the term "orchestator" does not match any use case i have. >>> >>> Let's be clear that there are four entities to a single transaction in >>> the real world sense of things. (and others that support the transacti= on.) >>> >>> Then we can focus on the end point roles. I will focus on the data >>> privacy issues, API's have the same parties with different terminology. >>> >>> 1. the subject of the data to be transferred. >>> >>> 2. the user of a grant from the subject to act as delegate. (see >>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the >>> user) >>> >>> 3. the site that has a repository of user data with legal obligations t= o >>> protect that data (the GDPR) (role resource server.) >>> >>> 4 the site that wants either access to the data, or some privacy >>> preserving statement about the existence and content of the data. (role= of >>> client, vendor, PISP, etc.) >>> >>> 5. some sorts of facilitator sites for allowing access (roles like >>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left >>> out of OAUTH for good reason. >>> >>> >>> >>> This is a note supporting the separation of roles from legal entities. >>> BTW, I firmly believe that the legal entity also needs to be ID'd by th= e >>> transaction. >>> >>> Peace ..tom >>> >>> >>> >>> >>> >>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>> wrote: >>> >>> Hi all >>> >>> >>> >>> I agree that "client" can be confusing. I would be in support of >>> alternative terminology. >>> >>> We can always have some wording that explains that an "Orchestrator" in >>> GNAP plays a similar role to "Client" in OAuth. >>> >>> >>> >>> Dave >>> >>> >>> >>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault >>> wrote: >>> >>> Hi Francis, >>> >>> >>> >>> I like your proposal, seems much more intuitive. >>> >>> >>> >>> Fabien >>> >>> >>> >>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>> =C3=A9crit : >>> >>> Hello Denis, Justin, Dick, Fabien, >>> >>> >>> >>> In this post ( >>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGN= w/) >>> i suggested we use the word "Orchestrator" to designate the piece of >>> software that orchestrate interaction between "Requestor" (a.k.a. User)= , AS >>> and RS to obtain the protected resource. >>> >>> >>> >>> We are turning around the same topic. As soon as we go beyond the >>> original oAuth protocol, the word 'Client' becomes confusing. >>> >>> >>> >>> In the same response, I suggest we talk about "roles" and not "entities= ". >>> >>> >>> >>> Best regards. >>> >>> /Francis >>> >>> >>> >>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: >>> >>> I still think that client was the right name in OAuth 2, as the client >>> wanted to do a client-server interaction, so the client used OAuth 2 to= get >>> an access token to interact with the "server". >>> >>> >>> >>> I do agree that it is not the best term in GNAP. Primarily because GNAP >>> is a combination of the client from OAuth 2, and the relying party from >>> OIDC. >>> >>> >>> >>> /Dick >>> >>> =E1=90=A7 >>> >>> >>> >>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >>> >>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>> >>> >>> >>> The term client in OAuth came from the computer science definition of >>> client-server interaction. >>> >>> >>> >>> This, I would argue, is exactly why it=E2=80=99s a bad label for someth= ing >>> that=E2=80=99s distinctly more specific in this context, and I would lo= ve to see >>> GNAP adopt a more specific label for the role that we traditionally cal= led >>> =E2=80=9Cclient=E2=80=9D in OAuth. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> >>> >>> The client is getting an access token so it can call a server, >>> specifically, a resource server (to differentiate it from the authoriza= tion >>> server). >>> >>> >>> >>> The confusion in my experience usually stems from people working with >>> software that is acting in multiple roles. IE, the software that is act= ing >>> as a client in once context, is also acting as an RS in other contexts,= or >>> even acting as an AS. The other confusion is that people view clients a= s >>> being the software the user is using -- although it may not be acting a= s a >>> client in the oauth context. >>> >>> >>> >>> >>> >>> >>> >>> =E1=90=A7 >>> >>> >>> >>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >>> wrote: >>> >>> Hi, >>> >>> >>> >>> To me, client has always been a strange word in the context of OAuth, a= s >>> it has a meaning well defined both in everyday life (this client is a g= ood >>> customer) and in computer science (client-server interaction). Thus I >>> always have to make the mental translation to the OAuth world before an= y >>> discussion... And any teaching experience shows that it does make the >>> concepts hard to grasp for a majority of (clever) people. >>> >>> >>> >>> As for the RO, previous discussions suggested Resource >>> Controller (RC) also, which may be a bit more specific than manager. >>> >>> >>> >>> Fabien >>> >>> >>> >>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>> >>> Justin and Dick, >>> >>> >>> >>> [Was: "Revisiting the photo sharing example (a driving use case for th= e >>> creation of OAuth)"] >>> >>> >>> >>> So let us attempt to define new terms: >>> >>> *initiating application (IA)*: application by means of which a user >>> initiates interactions with RS(s) and AS(s) >>> >>> In the same way, we should get rid of the term Resource Owner (RO), >>> which is currently defined as: >>> >>> Resource Owner (RO): entity capable of granting access to a protected >>> resource >>> >>> I propose to replace it with Resource Manager (RM): >>> >>> *Resource Manager (RM)* : application or user that manages an access >>> decision function of a Resource Server >>> >>> Denis >>> >>> >>> >>> I agree with Justin. Redefining well used terms will lead to significan= t >>> confusion. If we have a different role than what we have had in the pas= t, >>> then that role should have a name not being used already in OAuth or OI= DC. >>> >>> >>> >>> Given what we have learned, and my own experience explaining what a >>> Client is, and is not, improving the definition for Client could prove >>> useful. I am not suggesting the term be redefined, but clarified. >>> >>> >>> >>> For example, clarifying that a Client is a role an entity plays in the >>> protocol, and that the same entity may play other roles at other times,= or >>> some other language to help differentiate between "role" and "entity". >>> >>> >>> >>> /Dick >>> >>> =E1=90=A7 >>> >>> >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>> >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m >>> not really in favor of taking an existing term and applying a completel= y >>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>> and come up with a new, more specific and accurate term for the role th= an >>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diff= erent. We did this >>> in going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >>> >>> >>> >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is >>> ignore the fact that GNAP is going to be coming up in a world that is >>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t hav= e a blank >>> slate to work with, but neither are we bound to use the same terms and >>> constructs as before. It=E2=80=99s going to be a delicate balance! >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>> >>> >>> >>> I think that is fundamentally part of the question: >>> >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion >>> >>> >>> >>> If we say that this document assumes OAuth2.0 terminology, then we >>> should not change the meanings of any definition. If we are saying this >>> supersedes or replaces what OAuth 2.0 creates, then we should pick the = best >>> word for the job and ignore conflicting meanings from OAuth 2.0. I have= a >>> lot of first hand experience of industries "ruining words", and attempt= ing >>> to side-step the problem rather than redefining the word just confuses >>> everyone as everyone forgets the original meaning as new documents come >>> out, but the confusion with the use of a non-obvious word continues. >>> >>> >>> >>> Food for thought. >>> >>> - Warren >>> >>> >>> *Warren Parad* >>> >>> Founder, CTO >>> >>> Secure your user data and complete your authorization architecture. >>> Implement Authress . >>> >>> >>> >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>> >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response similar to the >>> one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in use= here. >>> What >>> > > you describe as RS2, which might in fact be an RS unto itself, is a >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world,= but it is not at >>> > > all the same as an OAuth client. I appreciate your mapping of the >>> > > entities below, but it makes it difficult to hold a discussion if w= e >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can >>> define >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>> definitions, >>> > > but we=E2=80=99ve got a chance to be more precise with how we defin= e things. >>> > >>> > In the ISO context, each document must define its own terminology. Th= e >>> > boiler plate for RFCs does not mandate a terminology or definitions >>> section >>> > but does not prevent it either. The vocabulary is limited and as long >>> as >>> > we clearly define what our terms are meaning, we can re-use a term >>> already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily mean that it is a >>> good idea to do so. We are clear that we are producing a protocol that >>> is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted Dic= k >>> to >>> use the term "GS" in XAuth, picking a name that was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> 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/ >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> >>> >>> *Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= / >>> . Moneyhub Financial Technology is regist= ered >>> in England & Wales, company registration number 06909772. Moneyhub >>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Bui= lding, >>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >> --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000003fc91805ac9ff41d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In GNAP the "Grant Client" is orchestrating/nego= tiating a grant on behalf of the Requestor. He is not the "Client"= ; of the "Grant". The real client is the Requestor.

We can assign this client the role of a "Negotiator" (if th= e word "Orchestrator" does not fit).

Best regards
/Francis

On Tue, Aug 11, 2020 at 3:49 P= M Dick Hardt <dick.hardt@gmail.c= om> wrote:
I agree that orchestrator may be a role in the protocol = -- it is not a role in XYZ or XAuth today.

Justin: would= you explain why you think the term "grant" is problematic? It is= in the WG name!

The client is receiving=C2=A0more= than access to resources from the GS, it is also receiving=C2=A0claims, so= "client of the resource" is too limiting.

Reading the definition of grant[1], it fits as a verb of what the GS is = doing, and fits as a noun of what the GS provides to the client.
=
A Grant Server is an Authorization Server in OAuth, and an O= penID Provider in OpenID Connect.
The Grant Client is a Client in= OAuth, and a Relying Party in OpenID Connect.

Hav= ing new terms (GS and GC) in GNAP, separating the roles from OAuth and Open= ID Connect.
It is straightforward=C2=A0to know what a GC and GS d= o when you understand that=C2=A0a grant is a combination of resource access= (from OAuth) and claims (from OpenID Connect).

/D= ick


On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> = wrote:
I ag= ree that =E2=80=9Corchestration=E2=80=9D is separate from what the classica= l =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2=80= =9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D concept= that=E2=80=99s been brought up here before, so I=E2=80=99m inclined to bel= ieve it can be a separate role from the client.

I person= ally think that =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a = =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of the r= esource=E2=80=9D.

I also think it=E2=80=99s proble= matic to lump in user claims with a =E2=80=9Cgrant=E2=80=9D and that=E2=80= =99s just going to muddle everything.=C2=A0

=C2=A0= =E2=80=94 Justin

On Aug 11, 2020= , at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comm= ents on preserving names when possible. The shift from "consumer"= in OAuth 1 to "client" in OAuth 2 was confusing to many.

I also echo Tom's comments about separating Entit= ies from Roles.

Orchestration[1] in my opinion is = not what the "client" is doing.

Below is= a stab at separating the entities and the roles

/= Dick

Tl;dr:=C2=A0
- Client=C2=A0-= > Grant Client
- added Relying Party, Claims Issuer, and Grant= Server Operator as entities

Roles - p= arties to the protocol
Grant Client (GC), Grant Server (GS), Reso= urce Server (RS)

Entities = - parties to a Trust Framework
User, Relying Party (RP), Claims Issuer = (Issuer), Grant Server Operator (GSO), Resource=C2=A0Owner (RO)
<= /div>

Grant -=C2=A0may contain claims and/o= r access to resources

#Protocol Roles
=

Grant Client (GC)
- used by User
=
- operated / provided by RP
- requests Grants from the GS
- access resources at an RS
- consumes Claims
<= br>
Grant Server (GS)
- operated by GSO
- may interact with the User=C2=A0
- may interact with the RO
- accepts grant requests from GCs
- issues grants to GCs=
- may issue claims

Resource Server<= /b> (RS)
- manages access to resources for the RO
- pro= vides access to resources for the GC
- accepts access granted by = the GS

#Legal Entities

=
User
- uses Grant Client
- may interact wit= h the Grant Server
- may also be a RO
- trusts RP, Issu= er, GSO

Relying Party (RP)
- prov= ides Grant Client to the User.
- may trust Issuers, GSOs, and RO= s

Claims Issuer (Issuer)
- issues= claims to RP
- may use GS or RS to issue claims

Grant Server Operator (GSO)
- operates the GS
- trusted by User, RP, and RO
- may also be an Issuer

Resource Owner (RO)
- owns res= ources at the RS
- trusts GSO to control access to the resources<= /div>
- may be same entity as the User
- may also be an = Issuer


<= div>

Orchestration (computing)

Fro= m Wikipedia, the free encyclopedia
Jump = to navigationJump to search
= In=C2=A0system administration,=C2= =A0orchestration=C2=A0is the automated=C2=A0configuration, coordination, and management of comput= er systems and=C2=A0software.[1]
A=C2=A0number= of tools exist=C2=A0for automation of server configuration and managem= ent, including=C2=A0Ansible,=C2=A0Puppet,=C2=A0Salt,=C2= =A0Terraform,[2]=C2=A0and=C2=A0AWS CloudFo= rmation.[3]

Usage[edit]

Orchestration is often discussed in the context of=C2=A0<= a href=3D"https://en.wikipedia.org/wiki/Service-oriented_architecture" titl= e=3D"Service-oriented architecture" style=3D"text-decoration-line:none;colo= r:rgb(11,0,128);background:none" target=3D"_blank">service-oriented archite= cture,=C2=A0virtualization,= =C2=A0provisioning,=C2=A0converged infrastructure=C2=A0and dynamic=C2=A0datacenter=C2=A0topics. Orchestration in this sense is about aligni= ng the business request with the applications, data, and infrastructure.[4]
In the context of=C2=A0cloud computing, the = main difference between=C2=A0workflow autom= ation=C2=A0and orchestration is that workflows are processed and comple= ted as processes within a single domain for automation purposes, whereas or= chestration includes a workflow and provides a directed action towards larg= er goals and objectives.[1]
In this context, and with the overa= ll aim to achieve specific goals and objectives (described through=C2=A0quality of service=C2=A0parameters), for exa= mple, meet application performance goals using minimized cost[5]=C2=A0and maxi= mize application performance within budget constraints.[6]








=
On Tue, Aug 11, 2020 at 9:33 AM Mike = Jones <= Michael.Jones@microsoft.com> wrote:

One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

=C2=A0

Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

= From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match= any use case i have.

Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would = be in support of alternative terminology.

We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive= .=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

=C2=A0

I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

The term client in OAuth came from the computer= science definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

=C2=A0

The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

Ju= stin and Dick,

=C2=A0

[W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

=C2=A0

So= let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

Re= source Owner (RO): entity capable of granting access to a protected resourc= e

I = propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

D= enis

=C2=A0

I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

=C2=A0

For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

=C2=A0

I think that is fundamentally part of the quest= ion:

We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warren Parad<= u>

Founder, CTO=

Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

=C2=A0

=C2=A0

Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


--
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/
--0000000000003fc91805ac9ff41d-- From nobody Tue Aug 11 13:35:45 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 02F523A0D93 for ; Tue, 11 Aug 2020 13:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 w0ez6o0XRa6T for ; Tue, 11 Aug 2020 13:35:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6A83A0D5C for ; Tue, 11 Aug 2020 13:35:32 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07BKZPZJ022290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Aug 2020 16:35:26 -0400 From: Justin Richer Message-Id: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_43395422-32C3-467E-91B0-C0C451A1F391" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 11 Aug 2020 16:35:25 -0400 In-Reply-To: Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" To: Dick Hardt References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 20:35:44 -0000 --Apple-Mail=_43395422-32C3-467E-91B0-C0C451A1F391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said = that your definition of it was problematic. Namely, the desire to lump = in claims about the user into the definition of the =E2=80=9Cgrant=E2=80=9D= .=20 =E2=80=94 Justin > On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: >=20 > I agree that orchestrator may be a role in the protocol -- it is not a = role in XYZ or XAuth today. >=20 > Justin: would you explain why you think the term "grant" is = problematic? It is in the WG name! >=20 > The client is receiving more than access to resources from the GS, it = is also receiving claims, so "client of the resource" is too limiting. >=20 > Reading the definition of grant[1], it fits as a verb of what the GS = is doing, and fits as a noun of what the GS provides to the client. >=20 > A Grant Server is an Authorization Server in OAuth, and an OpenID = Provider in OpenID Connect. > The Grant Client is a Client in OAuth, and a Relying Party in OpenID = Connect. >=20 > Having new terms (GS and GC) in GNAP, separating the roles from OAuth = and OpenID Connect. > It is straightforward to know what a GC and GS do when you understand = that a grant is a combination of resource access (from OAuth) and claims = (from OpenID Connect). >=20 > /Dick >=20 > [1] https://www.dictionary.com/browse/grant = > verb (used with object) > to bestow or confer, especially by a formal act: > to grant a charter. > to give or accord: > to grant permission. > to agree or accede to: > to grant a request. > to admit or concede; accept for the sake of argument: > I grant that point. > SEE MORE > noun > something granted, as a privilege or right, a sum of money, or a tract = of land: > Several major foundations made large grants to fund the research = project. > the act of granting. >=20 >=20 > [1]=20 >=20 >=20 >=20 > On Tue, Aug 11, 2020 at 12:31 PM Justin Richer > wrote: > I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the = classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the = term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80= =9D concept that=E2=80=99s been brought up here before, so I=E2=80=99m = inclined to believe it can be a separate role from the client. >=20 > I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as = it is not a =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Ccl= ient of the resource=E2=80=9D. >=20 > I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything.=20 >=20 > =E2=80=94 Justin >=20 >> On Aug 11, 2020, at 3:25 PM, Dick Hardt > wrote: >>=20 >> I echo Mike's comments on preserving names when possible. The shift = from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >>=20 >> I also echo Tom's comments about separating Entities from Roles. >>=20 >> Orchestration[1] in my opinion is not what the "client" is doing. >>=20 >> Below is a stab at separating the entities and the roles >>=20 >> /Dick >>=20 >> Tl;dr:=20 >> - Client -> Grant Client >> - added Relying Party, Claims Issuer, and Grant Server Operator as = entities >>=20 >> Roles - parties to the protocol >> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>=20 >> Entities - parties to a Trust Framework >> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server = Operator (GSO), Resource Owner (RO) >>=20 >> Grant - may contain claims and/or access to resources >>=20 >> #Protocol Roles >>=20 >> Grant Client (GC) >> - used by User >> - operated / provided by RP >> - requests Grants from the GS >> - access resources at an RS >> - consumes Claims >>=20 >> Grant Server (GS) >> - operated by GSO >> - may interact with the User=20 >> - may interact with the RO >> - accepts grant requests from GCs >> - issues grants to GCs >> - may issue claims >>=20 >> Resource Server (RS) >> - manages access to resources for the RO >> - provides access to resources for the GC >> - accepts access granted by the GS >>=20 >> #Legal Entities >>=20 >> User >> - uses Grant Client >> - may interact with the Grant Server >> - may also be a RO >> - trusts RP, Issuer, GSO >>=20 >> Relying Party (RP) >> - provides Grant Client to the User. >> - may trust Issuers, GSOs, and ROs >>=20 >> Claims Issuer (Issuer) >> - issues claims to RP >> - may use GS or RS to issue claims >>=20 >> Grant Server Operator (GSO) >> - operates the GS >> - trusted by User, RP, and RO >> - may also be an Issuer >>=20 >> Resource Owner (RO) >> - owns resources at the RS >> - trusts GSO to control access to the resources >> - may be same entity as the User >> - may also be an Issuer >>=20 >> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) = >>=20 >> Orchestration (computing) >> =46rom Wikipedia, the free encyclopedia >> Jump to navigation >> = Jump to = search >> = In = system administration = , orchestration is = the automated configuration = , coordination, = and management of computer systems and software = .[1] = >> A number of tools exist = for = automation of server configuration and management, including Ansible = , Puppet = , Salt = , Terraform = ,[2] = = and AWS CloudFormation = .[3] = >> Usage[edit = ] >> Orchestration is often discussed in the context of service-oriented = architecture = , = virtualization , = provisioning , converged = infrastructure = and dynamic datacenter = topics. Orchestration in this sense is about aligning the business = request with the applications, data, and infrastructure.[4] = >> In the context of cloud computing = , the main difference = between workflow automation = and orchestration is = that workflows are processed and completed as processes within a single = domain for automation purposes, whereas orchestration includes a = workflow and provides a directed action towards larger goals and = objectives.[1] = >> In this context, and with the overall aim to achieve specific goals = and objectives (described through quality of service = parameters), for = example, meet application performance goals using minimized cost[5] = and maximize application performance within budget = constraints.[6] = >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones = > = wrote: >> One of the things that people hated about OAuth was it invented new = terminology that wasn=E2=80=99t in common use. But for better or for = worse, the terms Client, Authorization Server, and Protected Resource = are now widely understood. >>=20 >> =20 >>=20 >> Let=E2=80=99s not make people similarly hate GNAP by inventing even = more novel terms, when existing terms will fit the bill. Client = wasn=E2=80=99t a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D = to the vocabulary menagerie would definitely make things worse. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: TXAuth > On Behalf Of Tom Jones >> Sent: Tuesday, August 11, 2020 8:44 AM >> To: Dave Tonge > >> Cc: Francis Pouatcha >; Justin = Richer >; Dick Hardt = >; Benjamin Kaduk = >; Fabien Imbault = >; Denis = >; txauth@ietf.org = >> Subject: Re: [GNAP] Terminology >>=20 >> =20 >>=20 >> the term "orchestator" does not match any use case i have. >>=20 >> Let's be clear that there are four entities to a single transaction = in the real world sense of things. (and others that support the = transaction.) >>=20 >> Then we can focus on the end point roles. I will focus on the data = privacy issues, API's have the same parties with different terminology. >>=20 >> 1. the subject of the data to be transferred. >>=20 >> 2. the user of a grant from the subject to act as delegate. (see = https://wiki.idesg.org/wiki/index.php/Delegation = for how to enable the = user) >>=20 >> 3. the site that has a repository of user data with legal obligations = to protect that data (the GDPR) (role resource server.) >>=20 >> 4 the site that wants either access to the data, or some privacy = preserving statement about the existence and content of the data. (role = of client, vendor, PISP, etc.) >>=20 >> 5. some sorts of facilitator sites for allowing access (roles like = authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left out of OAUTH for good reason. >>=20 >> =20 >>=20 >> This is a note supporting the separation of roles from legal = entities. BTW, I firmly believe that the legal entity also needs to be = ID'd by the transaction. >>=20 >> Peace ..tom >>=20 >> =20 >>=20 >> =20 >>=20 >> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: >>=20 >> Hi all >>=20 >> =20 >>=20 >> I agree that "client" can be confusing. I would be in support of = alternative terminology. >>=20 >> We can always have some wording that explains that an "Orchestrator" = in GNAP plays a similar role to "Client" in OAuth. >>=20 >> =20 >>=20 >> Dave >>=20 >> =20 >>=20 >> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault = > wrote: >>=20 >> Hi Francis, >>=20 >> =20 >>=20 >> I like your proposal, seems much more intuitive.=20 >>=20 >> =20 >>=20 >> Fabien=20 >>=20 >> =20 >>=20 >> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = > a =C3=A9crit : >>=20 >> Hello Denis, Justin, Dick, Fabien, >>=20 >> =20 >>=20 >> In this post = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ) i suggested we use the word "Orchestrator" to designate the piece of = software that orchestrate interaction between "Requestor" (a.k.a. User), = AS and RS to obtain the protected resource.=20 >>=20 >> =20 >>=20 >> We are turning around the same topic. As soon as we go beyond the = original oAuth protocol, the word 'Client' becomes confusing. >>=20 >> =20 >>=20 >> In the same response, I suggest we talk about "roles" and not = "entities". >>=20 >> =20 >>=20 >> Best regards. >>=20 >> /Francis >>=20 >> =20 >>=20 >> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > wrote: >>=20 >> I still think that client was the right name in OAuth 2, as the = client wanted to do a client-server interaction, so the client used = OAuth 2 to get an access token to interact with the "server". >>=20 >> =20 >>=20 >> I do agree that it is not the best term in GNAP. Primarily because = GNAP is a combination of the client from OAuth 2, and the relying party = from OIDC.=20 >>=20 >> =20 >>=20 >> /Dick >>=20 >> =E1=90=A7 >>=20 >> =20 >>=20 >> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > wrote: >>=20 >> On Aug 6, 2020, at 12:53 PM, Dick Hardt > wrote: >>=20 >> =20 >>=20 >> The term client in OAuth came from the computer science definition of = client-server interaction. >>=20 >> =20 >>=20 >> This, I would argue, is exactly why it=E2=80=99s a bad label for = something that=E2=80=99s distinctly more specific in this context, and I = would love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 >> The client is getting an access token so it can call a server, = specifically, a resource server (to differentiate it from the = authorization server). >>=20 >> =20 >>=20 >> The confusion in my experience usually stems from people working with = software that is acting in multiple roles. IE, the software that is = acting as a client in once context, is also acting as an RS in other = contexts, or even acting as an AS. The other confusion is that people = view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =E1=90=A7 >>=20 >> =20 >>=20 >> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault = > wrote: >>=20 >> Hi,=20 >>=20 >> =20 >>=20 >> To me, client has always been a strange word in the context of OAuth, = as it has a meaning well defined both in everyday life (this client is a = good customer) and in computer science (client-server interaction). Thus = I always have to make the mental translation to the OAuth world before = any discussion... And any teaching experience shows that it does make = the concepts hard to grasp for a majority of (clever) people. >>=20 >> =20 >>=20 >> As for the RO, previous discussions suggested Resource Controller = (RC) also, which may be a bit more specific than manager.=20 >>=20 >> =20 >>=20 >> Fabien=20 >>=20 >> =20 >>=20 >> On Thu, Aug 6, 2020 at 1:00 PM Denis > wrote: >>=20 >> Justin and Dick, >>=20 >> =20 >>=20 >> [Was: "Revisiting the photo sharing example (a driving use case for = the creation of OAuth)"] >>=20 >> =20 >>=20 >> So let us attempt to define new terms: >>=20 >> initiating application (IA): application by means of which a user = initiates interactions with RS(s) and AS(s) >>=20 >> In the same way, we should get rid of the term Resource Owner (RO), = which is currently defined as: >>=20 >> Resource Owner (RO): entity capable of granting access to a protected = resource >>=20 >> I propose to replace it with Resource Manager (RM): >>=20 >> Resource Manager (RM) : application or user that manages an access = decision function of a Resource Server >>=20 >> Denis >>=20 >> =20 >>=20 >> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>=20 >> =20 >>=20 >> Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>=20 >> =20 >>=20 >> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>=20 >> =20 >>=20 >> /Dick >>=20 >> =E1=90=A7 >>=20 >> =20 >>=20 >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >>=20 >> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>=20 >> =20 >>=20 >> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>=20 >>=20 >> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>=20 >> =20 >>=20 >> I think that is fundamentally part of the question: >>=20 >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion >>=20 >> =20 >>=20 >> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>=20 >> =20 >>=20 >> Food for thought. >>=20 >> - Warren >>=20 >>=20 >>=20 >>=20 >>=20 >> Warren Parad >>=20 >> Founder, CTO >>=20 >> Secure your user data and complete your authorization architecture. = Implement Authress . >>=20 >> =20 >>=20 >> =20 >>=20 >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>=20 >> Hi Denis, >>=20 >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> >=20 >> > Since you replied in parallel, I will make a response similar to = the one=20 >> > I sent to Dick. >> >=20 >> > > Hi Denis, >> > > >> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >> > > you describe as RS2, which might in fact be an RS unto itself, is = a=20 >> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >> > > all the same as an OAuth client. I appreciate your mapping of the=20= >> > > entities below, but it makes it difficult to hold a discussion if = we=20 >> > > aren=E2=80=99t using the same terms. >> > > >> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >> > > our own terms. The bad news is that this is really hard to do. >> > > >> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions,=20 >> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >> >=20 >> > In the ISO context, each document must define its own terminology. = The=20 >> > boiler plate for RFCs does not mandate a terminology or definitions = section >> > but does not prevent it either. The vocabulary is limited and as = long as=20 >> > we clearly define what our terms are meaning, we can re-use a term = already >> > used in another RFC. This is also the ISO approach. >>=20 >> Just because we can do something does not necessarily mean that it is = a >> good idea to do so. We are clear that we are producing a protocol = that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion. If I understand correctly, a similar reasoning prompted = Dick to >> use the term "GS" in XAuth, picking a name that was not already used = in >> OAuth 2.0. >>=20 >> -Ben >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> =20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> =20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> =20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> =20 >>=20 >> -- >>=20 >> Francis Pouatcha >>=20 >> Co-Founder and Technical Lead >>=20 >> adorsys GmbH & Co. KG >>=20 >> https://adorsys-platform.de/solutions/ = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> =20 >>=20 >> =20 >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) = athttps://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_43395422-32C3-467E-91B0-C0C451A1F391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said = that your definition of it was problematic. Namely, the desire to lump = in claims about the user into the definition of the = =E2=80=9Cgrant=E2=80=9D. 

 =E2=80=94 Justin

On Aug = 11, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be = a role in the protocol -- it is not a role in XYZ or XAuth today.

Justin: would you = explain why you think the term "grant" is problematic? It is in the WG = name!

The = client is receiving more than access to resources from the GS, it = is also receiving claims, so "client of the resource" is too = limiting.

Reading the definition of grant[1], it fits as a verb of what = the GS is doing, and fits as a noun of what the GS provides to the = client.

A = Grant Server is an Authorization Server in OAuth, and an OpenID Provider = in OpenID Connect.
The Grant Client is a Client in = OAuth, and a Relying Party in OpenID Connect.

Having new terms (GS and GC) in GNAP, = separating the roles from OAuth and OpenID Connect.
It is straightforward to know what a GC and GS do when = you understand that a grant is a combination of resource access = (from OAuth) and claims (from OpenID Connect).

/Dick

[1] https://www.dictionary.com/browse/grant

verb (used with = object)

to = bestow or confer, especially by a formal act:to grant a charter.
to = give or accord:to grant permission.
to = agree or accede to:to grant a request.
to = admit or concede; accept for the sake of argument:I grant that = point.
SEE MORE

noun

somethi= ng granted, as a privilege or right, a sum of money, or a tract of = land:Several major foundations made large grants to = fund the research project.
the = act of granting.


[1] 



On Tue, Aug = 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that =E2=80=9Corchestration=E2=80=9D is = separate from what the classical =E2=80=9Cclient=E2=80=9D in OAuth is = doing =E2=80=94 but the term =E2=80=9Corchestrator=E2=80=9D fits with = the =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been brought up = here before, so I=E2=80=99m inclined to believe it can be a separate = role from the client.

I personally think that =E2=80=9Cgrant client=E2=80=9D is = confusing as it is not a =E2=80=9Cclient of the grant=E2=80=9D but = rather a =E2=80=9Cclient of the resource=E2=80=9D.

I also think it=E2=80=99s = problematic to lump in user claims with a =E2=80=9Cgrant=E2=80=9D and = that=E2=80=99s just going to muddle everything. 

 =E2=80=94 = Justin

On Aug 11, 2020, at 3:25 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comments on = preserving names when possible. The shift from "consumer" in OAuth 1 to = "client" in OAuth 2 was confusing to many.

I also echo Tom's = comments about separating Entities from Roles.

Orchestration[1] in my opinion is not = what the "client" is doing.

Below is a stab at separating the entities and the = roles

/Dick

Tl;dr: 
- = Client -> Grant Client
- added Relying = Party, Claims Issuer, and Grant Server Operator as entities

Roles - parties to the protocol
Grant = Client (GC), Grant Server (GS), Resource Server (RS)

Entities - parties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant = Server Operator (GSO), Resource Owner (RO)

Grant - may contain claims and/or = access to resources

#Protocol Roles

Grant Client = (GC)
- used by User
- operated = / provided by RP
- requests Grants from the = GS
- access resources at an RS
-= consumes Claims

Grant Server (GS)
- = operated by GSO
- may interact with the = User 
- may interact with the RO
- accepts grant requests from GCs
- = issues grants to GCs
- may issue claims

Resource = Server (RS)
- manages access to resources for = the RO
- provides access to resources for the = GC
- accepts access granted by the GS

#Legal = Entities

User
- uses Grant Client
- may interact with the Grant Server
- = may also be a RO
- trusts RP, Issuer, GSO

Relying = Party (RP)
- provides Grant Client to the User. =
- may trust Issuers, GSOs, and ROs

Claims = Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant Server Operator = (GSO)
- operates the GS
- = trusted by User, RP, and RO
- may also be an = Issuer

Resource Owner (RO)
- = owns resources at the RS
- trusts GSO to control = access to the resources
- may be same entity as the = User
- may also be an = Issuer

[1] https://en.wikipedia.org/wiki/Orchestration_(computing)

Orchestration (computing)

=46rom Wikipedia, the free = encyclopedia
Jump to navigationJump to search
In system administration, orchestration is the automated configuration, coordination, and = management of computer systems and software.[1]
A number of tools exist for = automation of server configuration and management, including Ansible, Puppet, Salt, Terraform,[2] and AWS CloudFormation.[3]

Usage[edit]

Orchestration is often discussed in the context of service-oriented architecture, virtualization, provisioning, converged infrastructure and = dynamic datacenter topics. Orchestration = in this sense is about aligning the business request with the = applications, data, and infrastructure.[4]
In the context of cloud computing, the main difference = between workflow automation and = orchestration is that workflows are processed and completed as processes = within a single domain for automation purposes, whereas orchestration = includes a workflow and provides a directed action towards larger goals = and objectives.[1]
In this context, and with the overall aim to achieve = specific goals and objectives (described through quality of service parameters), = for example, meet application performance goals using minimized cost[5] and maximize application = performance within budget constraints.[6]








On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the things that people hated about OAuth was it = invented new terminology that wasn=E2=80=99t in common use.  But = for better or for worse, the terms Client, Authorization Server, and = Protected Resource are now widely understood.

 

Let=E2=80= =99s not make people similarly hate GNAP by inventing even more novel = terms, when existing terms will fit the bill.  Client wasn=E2=80=99t = a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the = vocabulary menagerie would definitely make things worse.

 

          &nb= sp;   =             &n= bsp;           &nbs= p;            =     -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

 

the term "orchestator" does not = match any use case i have.

Let's be clear that there are = four entities to a single transaction in the real world sense of things. = (and others that support the  transaction.)

Then we can focus on the end = point roles. I will focus on the data privacy issues, API's have the = same parties with different terminology.

1. the subject of the data to be = transferred.

2. the user of a grant from the = subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how = to enable the user)

3. the site that has a repository = of user data with legal obligations to protect that data (the GDPR) = (role resource server.)

4 the site that wants either = access to the data, or some privacy preserving statement about the = existence and content of the data. (role of client, vendor, PISP, = etc.)

5. some sorts of facilitator = sites for allowing access (roles like authenticator, idp, verifier, csp, = RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

 

This is a note supporting the = separation of roles from legal entities.  BTW, I firmly believe = that the legal entity also needs to be ID'd by the transaction.

Peace ..tom

 

 

On Tue, Aug 11, 2020 at 1:42 AM = Dave Tonge <dave.tonge@moneyhub.com> wrote:

Hi = all

 

I = agree that "client" can be confusing. I would be in support of = alternative terminology.

We = can always have some wording that explains that an "Orchestrator" in = GNAP plays a similar role to "Client" in OAuth.

 

Dave

 

On Tue, 11 Aug 2020 at 07:52, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Francis,

 

I like your proposal, seems much = more intuitive. 

 

Fabien 

 

Le mar. 11 ao=C3=BBt 2020 =C3=A0 = 04:17, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit :

Hello Denis, Justin, Dick, = Fabien,

 

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between = "Requestor" (a.k.a. User), AS and RS to obtain the protected = resource. 

 

We are turning around the same = topic. As soon as we go beyond the original oAuth protocol, the = word 'Client' becomes confusing.

 

In the same response, I = suggest we talk about "roles" and not "entities".

 

Best regards.

/Francis

 

On Thu, Aug 6, 2020 at 6:36 PM = Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the = right name in OAuth 2, as the client wanted to do a client-server = interaction, so the client used OAuth 2 to get an access token to = interact with the "server".

 

I do agree that it is not the = best term in GNAP. Primarily because GNAP is a combination of the client = from OAuth 2, and the relying party from OIDC. 

 

/Dick

=E1=90=A7

 

On Thu, Aug 6, 2020 at 12:50 PM = Justin Richer <jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

 

The term client in OAuth came = from the computer science definition of client-server interaction.

 

This, I would argue, is exactly = why it=E2=80=99s a bad label for something that=E2=80=99s distinctly = more specific in this context, and I would love to see GNAP adopt a more = specific label for the role that we traditionally called =E2=80=9Cclient=E2= =80=9D in OAuth.

 

 =E2=80=94 Justin



 

The client is getting an access = token so it can call a server, specifically, a resource server (to = differentiate it from the authorization server).

 

The confusion in my experience = usually stems from people working with software that is acting = in multiple roles. IE, the software that is acting as a client = in once context, is also acting as an RS in other contexts, or even = acting as an AS. The other confusion is that people view clients as being the = software the user is using -- although it may not be acting as a client = in the oauth context.

 

 

 

=E1=90=A7

 

On Thu, Aug 6, 2020 at 4:49 AM = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

 

To me, client has always been a = strange word in the context of OAuth, as it has a meaning well defined = both in everyday life (this client is a good customer) and in computer = science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And = any teaching experience shows that it does make the concepts hard to = grasp for a majority of (clever) people.

 

As for the RO, previous = discussions suggested Resource Controller (RC) also, which may = be a bit more specific than manager. 

 

Fabien 

 

On Thu, Aug 6, 2020 at 1:00 PM = Denis <denis.ietf@free.fr> wrote:

Justin and = Dick,

 

[Was:  = "Revisiting the photo sharing example (a driving use case for the = creation of OAuth)"]

 

So let us attempt to = define new terms:

initiating application = (IA): = application by means of which a user initiates interactions with RS(s) = and AS(s)

In the same way, we = should get rid of the term Resource Owner (RO), which is currently = defined as:

Resource Owner (RO): = entity capable of granting access to a protected resource

I propose to replace = it with Resource Manager (RM):

Resource Manager = (RM) = : application or user that manages an access decision function of a = Resource Server

Denis

 

I agree with Justin. Redefining = well used terms will lead to significant confusion. If we have a = different role than what we have had in the past, then that role = should have a name not being used already in OAuth or OIDC.

 

Given what we have learned, and = my own experience explaining what a Client is, and is not, improving the = definition for Client could prove useful. I am not suggesting the term = be redefined, but clarified. 

=

 

For example, clarifying that a = Client is a role an entity plays in the protocol, and that the same = entity may play other roles at other times, or some other language to = help differentiate between "role" and "entity".

 

/Dick

=E1=90=A7

 

On Wed, Aug 5, 2020 at 8:20 AM = Justin Richer <jricher@mit.edu> wrote:

I=E2=80=99m in favor of coming up = with a new term that=E2=80=99s a better fit, but I=E2=80=99m not really = in favor of taking an existing term and applying a completely new = definition to it. In other words, I would sooner stop using =E2=80=9Cclien= t=E2=80=9D and come up with a new, more specific and accurate term for the role than to define = =E2=80=9Cclient=E2=80=9D as meaning something completely different. We = did this in going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizat= ion Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

 

GNAP can do something similar, in = my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is = going to be coming up in a world that is already permeated  by = OAuth 2 and its terminology. We don=E2=80=99t have a blank slate to work = with, but neither are we bound to use the same terms and constructs as before. = It=E2=80=99s going to be a delicate balance!

 

 =E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, = Warren Parad <wparad@rhosys.ch> wrote:

 

I think that is fundamentally = part of the question:

We are clear that we are producing a protocol that = is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

 

If we say that this document = assumes OAuth2.0 terminology, then we should not change the meanings of = any definition. If we are saying this supersedes or replaces what OAuth = 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand = experience of industries "ruining words", and attempting to side-step = the problem rather than redefining the word just confuses everyone as = everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious = word continues.

 

Food for thought.

- Warren

Warren = Parad

Founder, = CTO

Secure your user data and complete your authorization = architecture. Implement Authress.

 

 

On Tue, Aug 4, 2020 at 8:53 PM = Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

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

 

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

 

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

 

--
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/

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

 

 

Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number 06909772. = Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject = to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are = made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's = business. Any opinions expressed in this email (or in any attachments) = are those of the author and do not necessarily represent the opinions of = Moneyhub Financial Technology Limited or of any other group company.


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



= --Apple-Mail=_43395422-32C3-467E-91B0-C0C451A1F391-- From nobody Tue Aug 11 14:27:21 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 D74D13A0D06 for ; Tue, 11 Aug 2020 14:27:19 -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 KXyLwFEG7SUP for ; Tue, 11 Aug 2020 14:27:17 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 50A7E3A0CF8 for ; Tue, 11 Aug 2020 14:27:17 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id g8so44367wmk.3 for ; Tue, 11 Aug 2020 14:27:17 -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=S5UDtSDdIPMmVLlqpoaPjhDWGA8RsgKBokDG0heisg8=; b=h6IIhtXkGCmDoUBlzMbXlNV2J2f+lZlSQ7isrDecYJFKhLrN1vsWlr9ZhMjsIYsJ1h D7+jKSc1yKte5b7iOtTHMjsS4E9MJ+WBE9Htqxf54AmIUxDl/QTTvE1AvldVk1qmnxx8 rRJEShNhB3rOrcJaqhsbEtwnFMt8iqBfzan6w= 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=S5UDtSDdIPMmVLlqpoaPjhDWGA8RsgKBokDG0heisg8=; b=oA8TxaEz1ijuzMJArG0imx9jw9/rr+ErQXQ4PVLLbpqEpleUbXdzz7jJWUsKwlskzY EdqJwKobNonTeFOV82+oAz5SvoS/4IZvoYSmkMCgVyCAD1hciKOfmnzPScGaXOhAUnET YY6HLT1vtDE2Fiik3pame+N7dBilivjp6WoABX7zwwIehQUazhcnxxp49x2KYU3o42dR FL5ChN/UrHwjbzVIenhbZZEe4W7+AJl2ey7oaXGkBV5o5/CkS/jCRXVuiFoipT8DM4iS RQLC1DD5y8Igppf3sklDomfMfCRiTEzqm0kPXqQV2s7c+b8YoNJoBmVd/9sCuXXd9KDD JUWg== X-Gm-Message-State: AOAM532H9A12v0VWzsRE8n1OqoAINXDXOVIgJfSwdKp/NNvDdMR1VtgX m+gkO7vJaBUvTIM5MTNCPLJN/k7PwQOFFw5LhRShCw== X-Google-Smtp-Source: ABdhPJy3sYNkTCicM3Yq0RUIjdPxvLagy4ODmm5+JaKHNNlUxnTnDYmmA4DzVKPMduhSEhQhSz4x6nFdd5lJJ/b8s+k= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr5327731wml.38.1597181235531; Tue, 11 Aug 2020 14:27:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 17:27:03 -0400 Message-ID: To: Fabien Imbault Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000002fa65405aca0bc13" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 21:27:20 -0000 --0000000000002fa65405aca0bc13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Fabian, On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault wrote: > Hi Francis, > > I think Denis points to the fact that, in the current situation, the AS > receives the resource request from the Client and therefore knows what > tokens are asked. > The token request must not mention any reference of the RS. > Then it also implements the consent interface (and possibly the login too= ) > and so it also knows who validates and what is accepted or not. > Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the RC in the token. SO AS can correlate on StudentId anyway. > I don't think the abstract flow deals with those privacy concerns. > To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and no AS. Best regards. /Francis > > > Then I agree with you on the audience field of the token, if left empty i= t > simplifies part of the problem, although it removes a big part of the > control you may want from directed tokens. That's why I'm willing to bett= er > develop the RS hiding idea. > > Fabien > > Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : > >> Hello Denis, >> >> what you describe in the use case seems to be the default behavior of th= e >> protocol. Let me map it with this abstract protocol flow: >> >> +-----------+ +--------------+ +-----------+ +----+ >> +---------------------+ >> | Requestor | | Orchestrator | | RS | | GS | | Resource >> Controller | >> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | is >> | >> | Staff | | Registr. App | | Server | | AS | | >> Student | >> +-----------+ +--------------+ +-----------+ +----+ >> +---------------------+ >> |(1) RegisterStudent | | | = | >> |---------------------->| | | = | >> | |(2) RequestRecordIntent(RecordType,StudentId, >> | | >> OrchestratorId):AuthRequest[RecordType,StudentId] >> | |<-------------->| | = | >> | | | | = | >> | |(3) >> AuthZRequest(RecordType,StudentId,OrchestratorId) >> | |--------------------------->| = | >> | | | |(4) >> ConsentRequest(RecordType, >> | | | | >> OrchestratorId):Consent >> | | | |<-------------->= | >> | |(5) AuthZ[RecordType,StudentId,OrchestratorId= ] >> | |<---------------------------| = | >> | | | | = | >> | |(2) >> RequestRecord(RecordType,StudentId,OrchestratorId) >> | | :RecordOf[StudentId] | = | >> | |<-------------->| | = | >> |(7) Registered | | | = | >> |<----------------------| | | = | >> + + + + = + >> >> we assume the authz request sent by "Client" to "AS" describes the >> protected resource without referring to the authz server. An AS can issu= e >> the authz to release the graduation record of a student >> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference = to >> the target university. >> >> What matters for this authz object is: >> - StudentId: a reference to the student as known to the resource server. >> - RecordType: a reference to a resource of type graduation record as >> understandable by the resource server. >> - OrchestratorId: reference to the Orchestrator. Can be used to bind >> authz to Orchestrator. >> >> But: >> - RS must trust AS issued token. >> - StudentId must be known to RS, AS and Orchestrator. >> >> Therefore, the AS does not need to know the RS. Keep the audience field >> empty. >> >> Same principle applies for the second use case. >> >> What privacy problem do you see here? >> >> Best regards. >> /Francis >> >> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >> >>> I tried my best twice to download three use cases in the Use cases >>> directory, but I failed. >>> >>> Rather than failing a third time, here is the direct link of the second >>> try: >>> >>> >>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-ca= ses-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>> >>> Denis >>> >>> >>> >>> >>> >>> >>> >>> -- >>> 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/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000002fa65405aca0bc13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17= AM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situa= tion, the AS receives the resource request from the Client and therefore kn= ows what tokens are asked.
The token request = must not mention any reference of the RS.
=C2=A0
= Then it also implements the consent interface (and possibly the login too) = and so it also knows who validates and what is accepted or not.
=
Decoupling this does not change the privacy context, as t= he AS issues the Token. AS needs to add a reference to the=C2=A0RC in the t= oken. SO AS can correlate on StudentId anyway.


I don't think the abstract flow deals wi= th those privacy concerns.=C2=A0
To solve the = privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) wa= y. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Cred= ential) to the Student (in his role of RC). The Student will then present t= his claim to UNIV-1 during his registration. In this case we need no Grant = negotiation and=C2=A0no AS.

Best regards.
/Francis
=C2=A0

Then I agree with you on the audience fie= ld of the token, if left empty it simplifies part of the problem, although = it removes a big part of the control you may want from directed tokens. Tha= t's why I'm willing to better develop the RS hiding idea.=C2=A0

Fabien=C2=A0
Le mar. 1= 1 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org= > a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,

what you= describe in the use case seems to be the default behavior of the protocol.= Let me map it with this abstract protocol flow:

<= div>+-----------+=C2=A0 =C2=A0 =C2=A0 +-----------= ---+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
| Re= questor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0= =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNI= V-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0A= S |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ = =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) RegisterStudent= =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0Orchestra= torId):AuthRequest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(RecordTyp= e,StudentId,OrchestratorId)
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|--------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorI= d):Consent
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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= =A0AuthZ[RecordType,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----= -----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,StudentId,OrchestratorId)=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7= ) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<-----= -----------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

we assume the authz request sent by "Client" to "AS"= describes the protected resource without referring=C2=A0to the authz serve= r. An AS can issue the authz to release the graduation record=C2=A0 of a st= udent ((5)=C2=A0AuthZ[RecordType,StudentId,OrchestratorId]), without any re= ference to the target university.=C2=A0

What matters for this= authz object is:
- StudentId: a = reference to the student as known to the resource server.
= - RecordType: a reference to a resource of type gr= aduation record as understandable=C2=A0 by the resource server.
-=C2=A0OrchestratorId: reference to the Orch= estrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS= , AS and=C2=A0Orchestrator.

<= /font>
Therefore, the AS does not need t= o know the RS. Keep the audience field empty.

Same principl= e applies for the second use case.

What privacy problem do yo= u see here?

Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <deni= s.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--0000000000002fa65405aca0bc13-- From nobody Tue Aug 11 15:09:56 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 665CA3A0EF4 for ; Tue, 11 Aug 2020 15:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 qQikxaARBxYO for ; Tue, 11 Aug 2020 15:09:39 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 303B03A0EB7 for ; Tue, 11 Aug 2020 15:09:32 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id t23so37852ljc.3 for ; Tue, 11 Aug 2020 15:09:32 -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=Oelk2jTKa9WSonaVzlqTrJRLBYujcpB3nHMmjXrgwYI=; b=Zsn4g/7YnBObIS0n4ZTfHkhQa/lfLziioDQofaIH2KE6Ql+HZ3Oz8bes6fgy6X6Mwu wDVdrdD24gyO+G20DpCoWdHteaSFJ376wiMYX8CuxJSTVCAK8wlPh6BvohTYR8gWCYko y3S3EmAUSsg1Cf/wUit8OmlKgAEB5U19WFcxLx8fq91nXsBu0HGxkmVovisNJjo/EIUW sxBBOHP/fdV5FhUcqoCcWgKxpMXN5O0KAvbqRzaQS2kM2kKpDz3MSHfZrdOyDGHy+Ety Yaa/5L7pnZC6VfeS4+0F966GMhtWpAWCbwmfBH1Jwl7jAi4FteQUEqt688J36x57SkL6 5XMg== 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=Oelk2jTKa9WSonaVzlqTrJRLBYujcpB3nHMmjXrgwYI=; b=pL4nBADGR/g86MJ1b+xE6WcMcZCzl15BHxwilyqkpSVEn631QE3k5ogJXtTMU6Bnm4 LyujL6DeT0mvZ8vepOCCwn3GuA9HTTp1LU/1bfNM+IgxQSMdRX7XdgwluIn6TWydn360 APQecgwxhJk3FJ9Iz1Xm+GSYSta18O7TTEGP2w3/zt7c5Dwh/M1p7kXriLCZ5VS8aCK5 NJHVWgdGxZjT6nLcM3FxX2SndoaYTtqhtFn+914eoK8oNvatnEXRbTiYH1OSVzEEBliF cn3nMUyE33/D1d7MPdHNT/Mv/NQroJrCVadMDi2pLeifdSJohk8MjMUFSSeDvJ+bQ+Ve wSQA== X-Gm-Message-State: AOAM533lzKvBz/mCS2tmLB7yONiDf17Zhd2NSrvwLyWtQlZDVw8Qn4e5 f/4vqyT+oCad5tCvxYRmNN1VBsyycfKG5uB3OnM= X-Google-Smtp-Source: ABdhPJxy313SynA5LKgOKm3HAc+uNKOv3P16oaoDhCm5Ka76CoSlL/utJZAqsjZpKy8I/CZ/1Fv7YNuXwFFGDsv9Dn0= X-Received: by 2002:a2e:b0db:: with SMTP id g27mr4091372ljl.69.1597183770081; Tue, 11 Aug 2020 15:09:30 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> In-Reply-To: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> From: Dick Hardt Date: Tue, 11 Aug 2020 15:08:53 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000041bfe105aca153bc" Archived-At: Subject: Re: [GNAP] Terminology 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, 11 Aug 2020 22:09:52 -0000 --00000000000041bfe105aca153bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A grant is whatever the client is asking from the server. Currently we have access to resources and identity claims. It could contain anything else an extension adds that a client may request from a server. Given the definition of grant that I included, why is grant not the right term to use for this? On Tue, Aug 11, 2020 at 1:35 PM Justin Richer wrote: > I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said th= at your > definition of it was problematic. Namely, the desire to lump in claims > about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. > > =E2=80=94 Justin > > On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: > > I agree that orchestrator may be a role in the protocol -- it is not a > role in XYZ or XAuth today. > > Justin: would you explain why you think the term "grant" is problematic? > It is in the WG name! > > The client is receiving more than access to resources from the GS, it is > also receiving claims, so "client of the resource" is too limiting. > > Reading the definition of grant[1], it fits as a verb of what the GS is > doing, and fits as a noun of what the GS provides to the client. > > A Grant Server is an Authorization Server in OAuth, and an OpenID Provide= r > in OpenID Connect. > The Grant Client is a Client in OAuth, and a Relying Party in OpenID > Connect. > > Having new terms (GS and GC) in GNAP, separating the roles from OAuth and > OpenID Connect. > It is straightforward to know what a GC and GS do when you understand > that a grant is a combination of resource access (from OAuth) and claims > (from OpenID Connect). > > /Dick > > [1] https://www.dictionary.com/browse/grant > verb (used with object) > to bestow or confer, especially by a formal act:to grant a charter. > to give or accord:to grant permission. > to agree or accede to:to grant a request. > to admit or concede; accept for the sake of argument:I grant that point. > SEE MORE > noun > something granted, as a privilege or right, a sum of money, or a tract of > land:Several major foundations made large grants to fund the research > project. > the act of granting. > > > [1] > > > > On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote: > >> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the c= lassical =E2=80=9Cclient=E2=80=9D >> in OAuth is doing =E2=80=94 but the term =E2=80=9Corchestrator=E2=80=9D = fits with the =E2=80=9Cuser agent=E2=80=9D >> concept that=E2=80=99s been brought up here before, so I=E2=80=99m incli= ned to believe it >> can be a separate role from the client. >> >> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as i= t is not a >> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of th= e resource=E2=80=9D. >> >> I also think it=E2=80=99s problematic to lump in user claims with a =E2= =80=9Cgrant=E2=80=9D and >> that=E2=80=99s just going to muddle everything. >> >> =E2=80=94 Justin >> >> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >> >> I echo Mike's comments on preserving names when possible. The shift from >> "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >> >> I also echo Tom's comments about separating Entities from Roles. >> >> Orchestration[1] in my opinion is not what the "client" is doing. >> >> Below is a stab at separating the entities and the roles >> >> /Dick >> >> *Tl;dr: * >> - Client -> Grant Client >> - added Relying Party, Claims Issuer, and Grant Server Operator as >> entities >> >> *Roles* - parties to the protocol >> Grant Client (GC), Grant Server (GS), Resource Server (RS) >> >> *Entities* - parties to a Trust Framework >> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operator >> (GSO), Resource Owner (RO) >> >> *Grant *- may contain claims and/or access to resources >> >> *#Protocol Roles* >> >> *Grant Client* (GC) >> - used by User >> - operated / provided by RP >> - requests Grants from the GS >> - access resources at an RS >> - consumes Claims >> >> *Grant Server* (GS) >> - operated by GSO >> - may interact with the User >> - may interact with the RO >> - accepts grant requests from GCs >> - issues grants to GCs >> - may issue claims >> >> *Resource Server* (RS) >> - manages access to resources for the RO >> - provides access to resources for the GC >> - accepts access granted by the GS >> >> *#Legal Entities* >> >> *User* >> - uses Grant Client >> - may interact with the Grant Server >> - may also be a RO >> - trusts RP, Issuer, GSO >> >> *Relying Party* (RP) >> - provides Grant Client to the User. >> - may trust Issuers, GSOs, and ROs >> >> *Claims Issuer* (Issuer) >> - issues claims to RP >> - may use GS or RS to issue claims >> >> *Grant Server Operator* (GSO) >> - operates the GS >> - trusted by User, RP, and RO >> - may also be an Issuer >> >> *Resource Owne*r (RO) >> - owns resources at the RS >> - trusts GSO to control access to the resources >> - may be same entity as the User >> - may also be an Issuer >> >> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >> >> Orchestration (computing) >> From Wikipedia, the free encyclopedia >> Jump to navigation >> Jump to >> search >> >> In system administration >> , *orchestration* i= s >> the automated configuration >> , coordination, >> and management of computer systems and software >> .[1] >> >> A number of tools exist >> for >> automation of server configuration and management, including Ansible >> , Puppet >> , Salt >> , Terraform >> ,[2] >> >> and AWS CloudFormation >> .[3] >> >> Usage[edit >> >> ] >> Orchestration is often discussed in the context of service-oriented >> architecture >> , >> virtualization , >> provisioning , converged >> infrastructure = and >> dynamic datacenter topics. >> Orchestration in this sense is about aligning the business request with = the >> applications, data, and infrastructure.[4] >> >> In the context of cloud computing >> , the main difference >> between workflow automation >> and orchestration is >> that workflows are processed and completed as processes within a single >> domain for automation purposes, whereas orchestration includes a workflo= w >> and provides a directed action towards larger goals and objectives.[1] >> >> In this context, and with the overall aim to achieve specific goals and >> objectives (described through quality of service >> parameters), for >> example, meet application performance goals using minimized cost[5] >> and >> maximize application performance within budget constraints.[6] >> >> >> >> >> >> >> >> >> >> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones >> wrote: >> >>> One of the things that people hated about OAuth was it invented new >>> terminology that wasn=E2=80=99t in common use. But for better or for w= orse, the >>> terms Client, Authorization Server, and Protected Resource are now wide= ly >>> understood. >>> >>> >>> >>> Let=E2=80=99s not make people similarly hate GNAP by inventing even mor= e novel >>> terms, when existing terms will fit the bill. Client wasn=E2=80=99t a = perfect >>> choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary mena= gerie would >>> definitely make things worse. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* TXAuth *On Behalf Of *Tom Jones >>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>> *To:* Dave Tonge >>> *Cc:* Francis Pouatcha ; Justin Richer ; >>> Dick Hardt ; Benjamin Kaduk ; >>> Fabien Imbault ; Denis ; >>> txauth@ietf.org >>> *Subject:* Re: [GNAP] Terminology >>> >>> >>> >>> the term "orchestator" does not match any use case i have. >>> >>> Let's be clear that there are four entities to a single transaction in >>> the real world sense of things. (and others that support the transacti= on.) >>> >>> Then we can focus on the end point roles. I will focus on the data >>> privacy issues, API's have the same parties with different terminology. >>> >>> 1. the subject of the data to be transferred. >>> >>> 2. the user of a grant from the subject to act as delegate. (see >>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the >>> user) >>> >>> 3. the site that has a repository of user data with legal obligations t= o >>> protect that data (the GDPR) (role resource server.) >>> >>> 4 the site that wants either access to the data, or some privacy >>> preserving statement about the existence and content of the data. (role= of >>> client, vendor, PISP, etc.) >>> >>> 5. some sorts of facilitator sites for allowing access (roles like >>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left >>> out of OAUTH for good reason. >>> >>> >>> >>> This is a note supporting the separation of roles from legal entities. >>> BTW, I firmly believe that the legal entity also needs to be ID'd by th= e >>> transaction. >>> >>> Peace ..tom >>> >>> >>> >>> >>> >>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>> wrote: >>> >>> Hi all >>> >>> >>> >>> I agree that "client" can be confusing. I would be in support of >>> alternative terminology. >>> >>> We can always have some wording that explains that an "Orchestrator" in >>> GNAP plays a similar role to "Client" in OAuth. >>> >>> >>> >>> Dave >>> >>> >>> >>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault >>> wrote: >>> >>> Hi Francis, >>> >>> >>> >>> I like your proposal, seems much more intuitive. >>> >>> >>> >>> Fabien >>> >>> >>> >>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>> =C3=A9crit : >>> >>> Hello Denis, Justin, Dick, Fabien, >>> >>> >>> >>> In this post ( >>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGN= w/) >>> i suggested we use the word "Orchestrator" to designate the piece of >>> software that orchestrate interaction between "Requestor" (a.k.a. User)= , AS >>> and RS to obtain the protected resource. >>> >>> >>> >>> We are turning around the same topic. As soon as we go beyond the >>> original oAuth protocol, the word 'Client' becomes confusing. >>> >>> >>> >>> In the same response, I suggest we talk about "roles" and not "entities= ". >>> >>> >>> >>> Best regards. >>> >>> /Francis >>> >>> >>> >>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: >>> >>> I still think that client was the right name in OAuth 2, as the client >>> wanted to do a client-server interaction, so the client used OAuth 2 to= get >>> an access token to interact with the "server". >>> >>> >>> >>> I do agree that it is not the best term in GNAP. Primarily because GNAP >>> is a combination of the client from OAuth 2, and the relying party from >>> OIDC. >>> >>> >>> >>> /Dick >>> >>> =E1=90=A7 >>> >>> >>> >>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >>> >>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>> >>> >>> >>> The term client in OAuth came from the computer science definition of >>> client-server interaction. >>> >>> >>> >>> This, I would argue, is exactly why it=E2=80=99s a bad label for someth= ing >>> that=E2=80=99s distinctly more specific in this context, and I would lo= ve to see >>> GNAP adopt a more specific label for the role that we traditionally cal= led >>> =E2=80=9Cclient=E2=80=9D in OAuth. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> >>> >>> The client is getting an access token so it can call a server, >>> specifically, a resource server (to differentiate it from the authoriza= tion >>> server). >>> >>> >>> >>> The confusion in my experience usually stems from people working with >>> software that is acting in multiple roles. IE, the software that is act= ing >>> as a client in once context, is also acting as an RS in other contexts,= or >>> even acting as an AS. The other confusion is that people view clients a= s >>> being the software the user is using -- although it may not be acting a= s a >>> client in the oauth context. >>> >>> >>> >>> >>> >>> >>> >>> =E1=90=A7 >>> >>> >>> >>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >>> wrote: >>> >>> Hi, >>> >>> >>> >>> To me, client has always been a strange word in the context of OAuth, a= s >>> it has a meaning well defined both in everyday life (this client is a g= ood >>> customer) and in computer science (client-server interaction). Thus I >>> always have to make the mental translation to the OAuth world before an= y >>> discussion... And any teaching experience shows that it does make the >>> concepts hard to grasp for a majority of (clever) people. >>> >>> >>> >>> As for the RO, previous discussions suggested Resource >>> Controller (RC) also, which may be a bit more specific than manager. >>> >>> >>> >>> Fabien >>> >>> >>> >>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>> >>> Justin and Dick, >>> >>> >>> >>> [Was: "Revisiting the photo sharing example (a driving use case for th= e >>> creation of OAuth)"] >>> >>> >>> >>> So let us attempt to define new terms: >>> >>> *initiating application (IA)*: application by means of which a user >>> initiates interactions with RS(s) and AS(s) >>> >>> In the same way, we should get rid of the term Resource Owner (RO), >>> which is currently defined as: >>> >>> Resource Owner (RO): entity capable of granting access to a protected >>> resource >>> >>> I propose to replace it with Resource Manager (RM): >>> >>> *Resource Manager (RM)* : application or user that manages an access >>> decision function of a Resource Server >>> >>> Denis >>> >>> >>> >>> I agree with Justin. Redefining well used terms will lead to significan= t >>> confusion. If we have a different role than what we have had in the pas= t, >>> then that role should have a name not being used already in OAuth or OI= DC. >>> >>> >>> >>> Given what we have learned, and my own experience explaining what a >>> Client is, and is not, improving the definition for Client could prove >>> useful. I am not suggesting the term be redefined, but clarified. >>> >>> >>> >>> For example, clarifying that a Client is a role an entity plays in the >>> protocol, and that the same entity may play other roles at other times,= or >>> some other language to help differentiate between "role" and "entity". >>> >>> >>> >>> /Dick >>> >>> =E1=90=A7 >>> >>> >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>> >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m >>> not really in favor of taking an existing term and applying a completel= y >>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>> and come up with a new, more specific and accurate term for the role th= an >>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diff= erent. We did this >>> in going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >>> >>> >>> >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is >>> ignore the fact that GNAP is going to be coming up in a world that is >>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t hav= e a blank >>> slate to work with, but neither are we bound to use the same terms and >>> constructs as before. It=E2=80=99s going to be a delicate balance! >>> >>> >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>> >>> >>> >>> I think that is fundamentally part of the question: >>> >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion >>> >>> >>> >>> If we say that this document assumes OAuth2.0 terminology, then we >>> should not change the meanings of any definition. If we are saying this >>> supersedes or replaces what OAuth 2.0 creates, then we should pick the = best >>> word for the job and ignore conflicting meanings from OAuth 2.0. I have= a >>> lot of first hand experience of industries "ruining words", and attempt= ing >>> to side-step the problem rather than redefining the word just confuses >>> everyone as everyone forgets the original meaning as new documents come >>> out, but the confusion with the use of a non-obvious word continues. >>> >>> >>> >>> Food for thought. >>> >>> - Warren >>> >>> >>> *Warren Parad* >>> >>> Founder, CTO >>> >>> Secure your user data and complete your authorization architecture. >>> Implement Authress . >>> >>> >>> >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>> >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response similar to the >>> one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in use= here. >>> What >>> > > you describe as RS2, which might in fact be an RS unto itself, is a >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world,= but it is not at >>> > > all the same as an OAuth client. I appreciate your mapping of the >>> > > entities below, but it makes it difficult to hold a discussion if w= e >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can >>> define >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>> definitions, >>> > > but we=E2=80=99ve got a chance to be more precise with how we defin= e things. >>> > >>> > In the ISO context, each document must define its own terminology. Th= e >>> > boiler plate for RFCs does not mandate a terminology or definitions >>> section >>> > but does not prevent it either. The vocabulary is limited and as long >>> as >>> > we clearly define what our terms are meaning, we can re-use a term >>> already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily mean that it is a >>> good idea to do so. We are clear that we are producing a protocol that >>> is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted Dic= k >>> to >>> use the term "GS" in XAuth, picking a name that was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> -- >>> 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/ >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >>> >>> >>> *Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= / >>> . Moneyhub Financial Technology is regist= ered >>> in England & Wales, company registration number 06909772. Moneyhub >>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Bui= lding, >>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >> > --00000000000041bfe105aca153bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A grant is whatever the client is asking from the server. = Currently we have access to resources and identity claims. It could contain= anything else an extension adds that a client may request from a server.
Given the definition of grant that I included, why is gra= nt not the right term to use for this?


On Tue, Aug 11, = 2020 at 1:35 PM Justin Richer <jriche= r@mit.edu> wrote:
I did not say the term= =E2=80=9Cgrant=E2=80=9D was problematic, I said that your definition of it= was problematic. Namely, the desire to lump in claims about the user into = the definition of the =E2=80=9Cgrant=E2=80=9D.=C2=A0

=C2= =A0=E2=80=94 Justin

On Aug 11, 2= 020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be a role in the protocol -- it is n= ot a role in XYZ or XAuth today.

Justin: would you expla= in why you think the term "grant" is problematic? It is in the WG= name!

The client is receiving=C2=A0more than acce= ss to resources from the GS, it is also receiving=C2=A0claims, so "cli= ent of the resource" is too limiting.

Reading= the definition of grant[1], it fits as a verb of what the GS is doing, and= fits as a noun of what the GS provides to the client.

=
A Grant Server is an Authorization Server in OAuth, and an OpenID Prov= ider in OpenID Connect.
The Grant Client is a Client in OAuth, an= d a Relying Party in OpenID Connect.

Having new te= rms (GS and GC) in GNAP, separating the roles from OAuth and OpenID Connect= .
It is straightforward=C2=A0to know what a GC and GS do when you= understand that=C2=A0a grant is a combination of resource access (from OAu= th) and claims (from OpenID Connect).

/Dick
<= div>
[1]=C2=A0https://www.dictionary.com/browse/grant

verb (used wi= th object)

to bestow or confer, especially by a formal act:to grant a charter.
to give or ac= cord:to grant permission.
=
= to= agree or accede to:to grant a request.
to admit or concede; accept for the sake of argument:I grant that point.

= noun

something granted, as a= privilege or right, a sum of money, or a tract of land:Several major foundations made large grants to fund the research= project.
the act of granting.


[1]=C2=A0

<= div>

On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote= :
I agree t= hat =E2=80=9Corchestration=E2=80=9D is separate from what the classical =E2= =80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2=80=9Corc= hestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D concept that= =E2=80=99s been brought up here before, so I=E2=80=99m inclined to believe = it can be a separate role from the client.

I personally = think that =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2= =80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of the reso= urce=E2=80=9D.

I also think it=E2=80=99s problemat= ic to lump in user claims with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s= just going to muddle everything.=C2=A0

=C2=A0=E2= =80=94 Justin

On Aug 11, 2020, a= t 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comment= s on preserving names when possible. The shift from "consumer" in= OAuth 1 to "client" in OAuth 2 was confusing to many.
<= div>
I also echo Tom's comments about separating Entities= from Roles.

Orchestration[1] in my opinion is not= what the "client" is doing.

Below is a = stab at separating the entities and the roles

/Dic= k

Tl;dr:=C2=A0
- Client=C2=A0->= ; Grant Client
- added Relying Party, Claims Issuer, and Grant Se= rver Operator as entities

Roles - part= ies to the protocol
Grant Client (GC), Grant Server (GS), Resourc= e Server (RS)

Entities - p= arties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Is= suer), Grant Server Operator (GSO), Resource=C2=A0Owner (RO)

Grant -=C2=A0may contain claims and/or a= ccess to resources

#Protocol Roles

Grant Client (GC)
- used by User
- operated / provided by RP
- requests Grants from the GS
=
- access resources at an RS
- consumes Claims

=
Grant Server (GS)
- operated by GSO
-= may interact with the User=C2=A0
- may interact with the RO
- accepts grant requests from GCs
- issues grants to GCs
- may issue claims

Resource Server= (RS)
- manages access to resources for the RO
- provid= es access to resources for the GC
- accepts access granted by the= GS

#Legal Entities

User
- uses Grant Client
- may interact with t= he Grant Server
- may also be a RO
- trusts RP, Issuer,= GSO

Relying Party (RP)
- provide= s Grant Client to the User.
- may trust Issuers, GSOs, and ROs

Claims Issuer (Issuer)
- issues cl= aims to RP
- may use GS or RS to issue claims

Grant Server Operator (GSO)
- operates the GS
<= div>- trusted by User, RP, and RO
- may also be an Issuer

Resource Owner (RO)
- owns resour= ces at the RS
- trusts GSO to control access to the resources
- may be same entity as the User
- may also be an Iss= uer


Orchestration (computing)

= >From Wikipedia, the free encyclopedia
Jump to navigationJump to search
In=C2=A0system administratio= n,=C2=A0orchestration=C2=A0is the automated=C2=A0configuration, coordination, and management = of computer systems and=C2=A0software.<= sup id=3D"gmail-m_-6047022440516396565gmail-m_-85048956776356592gmail-cite_= ref-Erl_1-0" style=3D"line-height:1;unicode-bidi:isolate;white-space:nowrap= ;font-size:14px">[1]
A=C2=A0number of tools exist=C2=A0for automation of server configuration = and management, including=C2=A0Ansible,= =C2=A0Puppet,=C2=A0= Salt,=C2=A0Terraform,= [2]=C2=A0and=C2=A0AWS CloudFormation.[3]

Usage[edit<= /a>]
Orchestration is often discussed in the = context of=C2=A0service= -oriented architecture,=C2=A0vi= rtualization,=C2=A0provisioning,=C2=A0converged infrastructure=C2=A0and dynami= c=C2=A0datacenter=C2=A0topics. Orchestration in this sens= e is about aligning the business request with the applications, data, and i= nfrastructure.[4]
In the context of=C2=A0cloud = computing, the main difference between=C2=A0workflow automation=C2=A0and orchestration is that workflows are p= rocessed and completed as processes within a single domain for automation p= urposes, whereas orchestration includes a workflow and provides a directed = action towards larger goals and objectives.[1]
In this cont= ext, and with the overall aim to achieve specific goals and objectives (des= cribed through=C2=A0quality of service=C2= =A0parameters), for example, meet application performance goals using minim= ized cost[5= ]=C2=A0and maximize application performance within budget constra= ints.[6= ]







=
On Tue, Au= g 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

=C2=A0

Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

= From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match= any use case i have.

Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would = be in support of alternative terminology.

We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive= .=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

=C2=A0

I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

The term client in OAuth came from the computer= science definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

=C2=A0

The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

Ju= stin and Dick,

=C2=A0

[W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

=C2=A0

So= let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

Re= source Owner (RO): entity capable of granting access to a protected resourc= e

I = propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

D= enis

=C2=A0

I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

=C2=A0

For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

=C2=A0

I think that is fundamentally part of the quest= ion:

We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warren Parad<= u>

Founder, CTO=

Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

=C2=A0

=C2=A0

Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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



--00000000000041bfe105aca153bc-- From nobody Tue Aug 11 15:22:15 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 7680A3A0D4F for ; Tue, 11 Aug 2020 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_KAM_HTML_FONT_INVALID=0.01, 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 VvuSOHEpwqdv for ; Tue, 11 Aug 2020 15:22:10 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 463A43A0C87 for ; Tue, 11 Aug 2020 15:22:10 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id f26so40068ljc.8 for ; Tue, 11 Aug 2020 15:22:10 -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=NCfeAYYB796Hjq3dhiBkn+lqYH4jeUZxR2eTCHiXc1A=; b=Q+B1V5kKtELynqn/DLAHwOEo5378VgLjzwmlz2cCgN5R2Gcg26hCplJU5GoqH8IIDx EDIgHvCI+NWzFdwSsaLufC8dXg8KJmMDQssNe1pOwWyFsH2GuULm5UKA1bJhGhyO8FgI KXf9RKgAgOU42UYLDGvJm9uv0/pwlZ5Ftn0fOlet+ygvZbZ1k1yrazU9PqfCT76pFN2/ +xxMOQh4C8hr7H9ig/STHxInBjygDIzLdt1yBucX9VGQrDPIgNboh7bx7fjEuM5ro1Yh TxpUZLmU04WOiA2Ucl8707snNmPT0QOlSuapmYzmW3ILcWAXm1hbLZZs7BGeHm+bXna9 wB1w== 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=NCfeAYYB796Hjq3dhiBkn+lqYH4jeUZxR2eTCHiXc1A=; b=GnBZDapHKquw6F62N62ZpBDwYJS1JxFnJ+xV+3dUTBzhxNdmqR0Yf7Y5nGnBrV5C6z OZqXGxngCOHU0B8jyYHEzKbqJiqHnzWwqpc/DboYhXnPrAwh+uq7sopcCE+B8XZJXIu1 Oq2VO6GZ+HvbRXWbzlORIE77RnWnKHsSnh6+cvrOET+vR3QnvsZL2V51GV0eNt7FebQY BDpKVv/DpB7JQF1Pmjm7OX1jp+YlKJ4H/bKbol78KBmZgc6NxPYmCCzXI21dEqtNLf/4 1CxVb1wziLyJRDDYzgEL/C55DPC4DL48Exh0t1p6wmyJkYiVLro6sQ+Lda0WisO9zfPO 6e/g== X-Gm-Message-State: AOAM5309MBiBYMefjjPZ3vXuaifUsYHu2oVm0QOJWO10zG7yaefXpqcT JxqHZc1rKpJUG8NmsJHVoPhPZTR1DdfM3vdjYnQ= X-Google-Smtp-Source: ABdhPJwQHLGncObom9FIh8VDsqXbZQUKCNbAOPLoThNSfEu9HZbclIPxFiJyBkejQt4tugPnfSnM0+Ye6f6s+OWoV9M= X-Received: by 2002:a2e:9695:: with SMTP id q21mr3695151lji.437.1597184528208; Tue, 11 Aug 2020 15:22:08 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 15:21:32 -0700 Message-ID: To: Francis Pouatcha Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000071d98105aca18051" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 11 Aug 2020 22:22:14 -0000 --00000000000071d98105aca18051 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening. I also think that (2) could be an extension to GNAP, rather than part of the core protocol. On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha wrote: > In this context, I suggest we pick some words to work with, and sharpen > them as we move on, discover and map new use cases to the protocol. > > In this diagram from the original thread ( > https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= ), > I replaced the words: > > +-----------+ +--------------+ +----+ +----+ > +---------------------+ > | Requestor | | Orchestrator | | | | GS | | Resource Controlle= r > | > | was | | was | | RS | | or | | was > | > | User | | Client | | | | AS | | Resource Owner > | > +-----------+ +--------------+ +----+ +----+ > +---------------------+ > |(1) ServiceRequest | | | | > |---------------------->| | | | > | |(2) ServiceIntent:AuthZChallenge | > | |<---------->| | | > | | | | | > | |(3) AuthZRequest(AuthZChallenge) | > | |------------------->| | > | | | |(4) ConsentRequest:Grant > | | | |<-------------->| > | |(5) GrantAccess(AuthZ) | > | |<-------------------| | > | | | | | > | |(6) ServiceRequest(AuthZ):ServiceResponse > | |<---------->| | | > |(7) ServiceResponse | | | | > |<----------------------| | | | > + + + + + > > The purpose of the GNAP protocol is to help negotiate access to a > protected resource. It starts with a requestor delegating activity to an > orchestrator. These are all roles, no entities. Let focus on mapping the > use cases to the protocol roles and interactions so wwe can discover what > is missing. > > It seems cumbersome to use it in discussions as it is impossible to give > the word "Client" a clear definition. > > We can mention in the final document, that the "Orchestrator" (or whateve= r > word we finally use) plays the same role as the "Client" in oAuth2. > > Best regards. > /Francis > > > > > > On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt wrote: > >> I agree with Justin. Redefining well used terms will lead to significant >> confusion. If we have a different role than what we have had in the past= , >> then that role should have a name not being used already in OAuth or OID= C. >> >> Given what we have learned, and my own experience explaining what a >> Client is, and is not, improving the definition for Client could prove >> useful. I am not suggesting the term be redefined, but clarified. >> >> For example, clarifying that a Client is a role an entity plays in the >> protocol, and that the same entity may play other roles at other times, = or >> some other language to help differentiate between "role" and "entity". >> >> /Dick >> =E1=90=A7 >> >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > > wrote: >> >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m >>> not really in favor of taking an existing term and applying a completel= y >>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>> and come up with a new, more specific and accurate term for the role th= an >>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diff= erent. We did this >>> in going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >>> >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is >>> ignore the fact that GNAP is going to be coming up in a world that is >>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t hav= e a blank >>> slate to work with, but neither are we bound to use the same terms and >>> constructs as before. It=E2=80=99s going to be a delicate balance! >>> >>> =E2=80=94 Justin >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>> >>> I think that is fundamentally part of the question: >>> >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion >>> >>> >>> If we say that this document assumes OAuth2.0 terminology, then we >>> should not change the meanings of any definition. If we are saying this >>> supersedes or replaces what OAuth 2.0 creates, then we should pick the = best >>> word for the job and ignore conflicting meanings from OAuth 2.0. I have= a >>> lot of first hand experience of industries "ruining words", and attempt= ing >>> to side-step the problem rather than redefining the word just confuses >>> everyone as everyone forgets the original meaning as new documents come >>> out, but the confusion with the use of a non-obvious word continues. >>> >>> Food for thought. >>> - Warren >>> >>> Warren Parad >>> Founder, CTO >>> Secure your user data and complete your authorization architecture. >>> Implement Authress . >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>> >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a response similar to the >>>> one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in us= e here. >>>> What >>>> > > you describe as RS2, which might in fact be an RS unto itself, is = a >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client= of RS1/. What >>>> you >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world= , but it is not >>>> at >>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>> > > entities below, but it makes it difficult to hold a discussion if >>>> we >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can >>>> define >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>> definitions, >>>> > > but we=E2=80=99ve got a chance to be more precise with how we defi= ne things. >>>> > >>>> > In the ISO context, each document must define its own terminology. >>>> The >>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>> section >>>> > but does not prevent it either. The vocabulary is limited and as lon= g >>>> as >>>> > we clearly define what our terms are meaning, we can re-use a term >>>> already >>>> > used in another RFC. This is also the ISO approach. >>>> >>>> Just because we can do something does not necessarily mean that it is = a >>>> good idea to do so. We are clear that we are producing a protocol tha= t >>>> is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted >>>> Dick to >>>> use the term "GS" in XAuth, picking a name that was not already used i= n >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> 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/ > --00000000000071d98105aca18051 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis

The user is an entity, not a= role in the protocol in how I am defining roles, so steps (1) and (7) are = confusing to me on what is happening.

I also think= that (2) could be an extension to GNAP, rather than part of the core proto= col.





On Mo= n, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de> wrote:
In this cont= ext, I suggest we pick some words to work with, and sharpen them as we move= on, discover and map new use cases to the protocol.

In this diagr= am from the original thread (https://ma= ilarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:
+-----------+=C2=A0 =C2=A0 =C2=A0 +---= -----------+ =C2=A0+----+ =C2=A0+----+ =C2=A0+---------------------+
| R= equestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0 =C2=A0 | =C2= =A0| GS | =C2=A0| Resource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0RS=C2=A0|=C2=A0 |=C2=A0= or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
|=C2=A0 User=C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0= |=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 Resource Ow= ner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2= =A0+----+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) Service= Request=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZCha= llenge=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 = =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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) ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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) Gran= tAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ)= :ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the G= NAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating a= ctivity to an orchestrator. These are all roles, no entities. Let focus on = mapping the use cases to the protocol roles and interactions so wwe can dis= cover what is missing.

It seems cum= bersome to use it in discussions as it is impossible to give the word "= ;Client" a clear definition.

W= e can mention=C2=A0in the final document, that the "Orchestrator"= (or whatever word we finally use) plays the same role as the "Client&= quot; in oAuth2.
Best regards.
/Francis

<= br>



On Wed, Aug 5, 2020 at 9:05 P= M Dick Hardt <= dick.hardt@gmail.com> wrote:
I agree with Justin. Redefining well u= sed terms will lead to significant confusion. If we have a different role t= han what we have had in=C2=A0the past, then that role should have a name no= t being used already in OAuth or OIDC.

Given what we hav= e learned, and my own experience explaining what a Client is, and is not, i= mproving the definition for Client could prove useful. I am not suggesting = the term be redefined, but clarified.=C2=A0

For ex= ample, clarifying that a Client is a role an entity plays in the protocol, = and that the same entity may play other roles at other times, or some other= language to help differentiate between "role" and "entity&q= uot;.

/Dick
3D""=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I=E2=80=99m in favor of= coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m not= really in favor of taking an existing term and applying a completely new d= efinition to it. In other words, I would sooner stop using =E2=80=9Cclient= =E2=80=9D and come up with a new, more specific and accurate term for the r= ole than to define =E2=80=9Cclient=E2=80=9D as meaning something completely= different. We did this in going from OAuth 1 to OAuth 2 already, moving fr= om the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D= at all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead al= ways qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9C= Resource Server=E2=80=9D.

GNAP can do something similar,= in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP i= s going to be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to work with, b= ut neither are we bound to use the same terms and constructs as before. It= =E2=80=99s going to be a delicate balance!

=C2=A0= =E2=80=94 Justin

On = Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to = OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitio= ns may lead to unnecessary
confusion

If = we say that this document assumes OAuth2.0 terminology, then we should not = change the meanings of any definition. If we are saying this supersedes or = replaces what OAuth 2.0 creates, then we should pick the best word for the = job and ignore conflicting meanings from OAuth 2.0. I have a lot of first h= and experience of industries "ruining words", and attempting to s= ide-step the problem rather than redefining the word just confuses everyone= as everyone forgets the original meaning as new documents come out, but th= e confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

Warren Parad
= Founder, CTO
Secure your user data and complete your authorization arch= itecture. Implement=C2=A0Authress.


On Tue, Aug 4, 2020 at 8:53 P= M Benjamin Kaduk <kad= uk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--00000000000071d98105aca18051-- From nobody Tue Aug 11 15:27:36 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 791843A0DA6 for ; Tue, 11 Aug 2020 15:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 auPs86WuVkah for ; Tue, 11 Aug 2020 15:27:26 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 1BFA13A0DBE for ; Tue, 11 Aug 2020 15:27:26 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id k12so436198otr.1 for ; Tue, 11 Aug 2020 15:27:26 -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=ZvIndcmeRy/HfupP41qhxap70B+Lpv+Cz04sR8v+b48=; b=LqalrW99mZwwh/IFcI+JNeH7SP7AaM7O7BVBgTdThAw0T8TfSj5Gc/nMUiJ6j2Akl2 /Ya1xK5gGiOFnl/drwbldWhvR51qGrhfTAtsx1I8sxg9AaGFSUl6yGve8PpSsfh+rwI+ fliXNR7cSh3S0vznOBLaAz4XHNbV9QzO+RQRAhhDj+rvPLraBER4HcYSU+JE4NIjWkM9 moeEylj/mOFhRjsZwtP3KOQQyx9RtAYgFwtEV7xJUIDxZzJoMq+qFrYK2qWKgUjRt3r0 8Zz52lU0wVwy/lak7S2t2cqhqGg02EtygWTGJ74SaDjTEDNOLgHD3FkGTjNQimFW2Giz Ocaw== 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=ZvIndcmeRy/HfupP41qhxap70B+Lpv+Cz04sR8v+b48=; b=py7BPGa5lF3cLZltKjMYRf9C0VJGxRwqYkzdSf1nBQtqZVlzavgGvyg+UXrNk38PRy tyYaK29rUi/7FrHlpGcp/xw4JKxW8eK2otMKZgcapCdgEjcm94hgH8a8+0mq1YsKOsRC jpOhouWbojQXjqiyycHMTw0uMg8X5XXyu+IYC5kHVq2/1zUpl9z1UQgmoLTlmFfEFUYd Kyr6DzG5aK2qZd58fe/Elkzr9BoZVQi+brrGSgv0JOs7eMO9PahzOh7et6IKzKC9RKBl y8KSAxHNctn7YTjlTO/BtCf76+OnCYlr0LU84RsyiuKkBvtPvvoLAGfr+1xBIQSEmE4+ fK6A== X-Gm-Message-State: AOAM532c/0mojk+BZKgKpj/X6TMHAt6UqJbxmqcWKrkHhKYVFwrcOHWU hRnTYT92yim89XlBflBzR5gEFFo0dH3cXrt5io0= X-Google-Smtp-Source: ABdhPJzAmLEZ+bhZc/IDOXUfdFWHCuJWNxAP3Pf2pfHvhqpRtjeSfWhTeBkAMKBf2obyJkpGt+aBp8EPHXd9kDXrLfU= X-Received: by 2002:a9d:3e49:: with SMTP id h9mr6633710otg.87.1597184845186; Tue, 11 Aug 2020 15:27:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Tue, 11 Aug 2020 15:27:13 -0700 Message-ID: To: Francis Pouatcha Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005688b405aca19383" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 22:27:35 -0000 --0000000000005688b405aca19383 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "The token request must not mention any reference of the RS." this cannot be an absolute rule. I have cases were the client needs to tell the user which they are coming back for additional grants. The reason is typically because a request by the client for data/access from the rs was rejected. The reason for the rejection is important for the client to make the case to the user for additional permissions. Peace ..tom On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha wrote: > Hello Fabian, > > On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault > wrote: > >> Hi Francis, >> >> I think Denis points to the fact that, in the current situation, the AS >> receives the resource request from the Client and therefore knows what >> tokens are asked. >> > The token request must not mention any reference of the RS. > > >> Then it also implements the consent interface (and possibly the login >> too) and so it also knows who validates and what is accepted or not. >> > Decoupling this does not change the privacy context, as the AS issues the > Token. AS needs to add a reference to the RC in the token. SO AS can > correlate on StudentId anyway. > > >> I don't think the abstract flow deals with those privacy concerns. >> > To solve the privacy problem addressed in this thread, we need to go the > (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC > (Verifiable Credential) to the Student (in his role of RC). The Student > will then present this claim to UNIV-1 during his registration. In this > case we need no Grant negotiation and no AS. > > Best regards. > /Francis > >> > >> >> Then I agree with you on the audience field of the token, if left empty >> it simplifies part of the problem, although it removes a big part of the >> control you may want from directed tokens. That's why I'm willing to bet= ter >> develop the RS hiding idea. >> >> Fabien >> >> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >> >>> Hello Denis, >>> >>> what you describe in the use case seems to be the default behavior of >>> the protocol. Let me map it with this abstract protocol flow: >>> >>> +-----------+ +--------------+ +-----------+ +----+ >>> +---------------------+ >>> | Requestor | | Orchestrator | | RS | | GS | | Resource >>> Controller | >>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>> is | >>> | Staff | | Registr. App | | Server | | AS | | >>> Student | >>> +-----------+ +--------------+ +-----------+ +----+ >>> +---------------------+ >>> |(1) RegisterStudent | | | = | >>> |---------------------->| | | = | >>> | |(2) RequestRecordIntent(RecordType,StudentId= , >>> | | >>> OrchestratorId):AuthRequest[RecordType,StudentId] >>> | |<-------------->| | = | >>> | | | | = | >>> | |(3) >>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>> | |--------------------------->| = | >>> | | | |(4) >>> ConsentRequest(RecordType, >>> | | | | >>> OrchestratorId):Consent >>> | | | |<--------------= >| >>> | |(5) AuthZ[RecordType,StudentId,OrchestratorI= d] >>> | |<---------------------------| = | >>> | | | | = | >>> | |(2) >>> RequestRecord(RecordType,StudentId,OrchestratorId) >>> | | :RecordOf[StudentId] | = | >>> | |<-------------->| | = | >>> |(7) Registered | | | = | >>> |<----------------------| | | = | >>> + + + + = + >>> >>> we assume the authz request sent by "Client" to "AS" describes the >>> protected resource without referring to the authz server. An AS can iss= ue >>> the authz to release the graduation record of a student >>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference= to >>> the target university. >>> >>> What matters for this authz object is: >>> - StudentId: a reference to the student as known to the resource server= . >>> - RecordType: a reference to a resource of type graduation record as >>> understandable by the resource server. >>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>> authz to Orchestrator. >>> >>> But: >>> - RS must trust AS issued token. >>> - StudentId must be known to RS, AS and Orchestrator. >>> >>> Therefore, the AS does not need to know the RS. Keep the audience field >>> empty. >>> >>> Same principle applies for the second use case. >>> >>> What privacy problem do you see here? >>> >>> Best regards. >>> /Francis >>> >>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>> >>>> I tried my best twice to download three use cases in the Use cases >>>> directory, but I failed. >>>> >>>> Rather than failing a third time, here is the direct link of the secon= d >>>> try: >>>> >>>> >>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-c= ases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>> >>>> Denis >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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/ >>> -- >>> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005688b405aca19383 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"The token request must= not mention any reference of the RS."
this cannot be an abs= olute rule. I have cases were the client needs to tell the user which they = are coming back for additional grants.
The reason is typically be= cause a request by the client for data/access from the rs was rejected. The= reason for the rejection is important for the client to make the case to t= he user for additional permissions.
Peace ..tom
=



On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha <fpo=3D= 40adorsys.de@dmarc.ietf.org<= /a>> wrote:
<= div dir=3D"ltr">
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 = AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in = the current situation, the AS receives the resource request from the Client= and therefore knows what tokens are asked.
T= he token request must not mention any reference of the RS.
=C2=A0=
<= div dir=3D"auto">Then it also implements the consent interface (and possibl= y the login too) and so it also knows who validates and what is accepted or= not.
Decoupling this does not change the priv= acy context, as the AS issues the Token. AS needs to add a reference to the= =C2=A0RC in the token. SO AS can correlate on StudentId anyway.
<= br>

I don't think the abstr= act flow deals with those privacy concerns.=C2=A0
<= div>To solve the privacy problem addressed in this thread, we need to go th= e (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC= (Verifiable Credential) to the Student (in his role of RC). The Student wi= ll then present this claim to UNIV-1 during his registration. In this case = we need no Grant negotiation and=C2=A0no AS.

Best = regards.
/Francis
= =C2=A0

Then I agree with you on= the audience field of the token, if left empty it simplifies part of the p= roblem, although it removes a big part of the control you may want from dir= ected tokens. That's why I'm willing to better develop the RS hidin= g idea.=C2=A0

Fabien=C2= =A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo= =3D40adors= ys.de@dmarc.ietf.org> a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,
what you describe in the use case seems to be the default behav= ior of the protocol. Let me map it with this abstract protocol flow:
<= div>
+-----------+=C2=A0 =C2=A0= =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+----------= -----------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|= =C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Control= ler |
| is UNIV-1 |=C2=A0 =C2=A0 = =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2= =A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
|=C2=A0 =C2=A0Staff= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 = =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+= =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |= (1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |----------------------&= gt;|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,Stude= ntId,
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0OrchestratorId):AuthRequest[RecordType,StudentId]
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) = AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------------------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0OrchestratorId):Consent
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |= =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=A0AuthZ[RecordType,StudentId,OrchestratorId]
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,Stud= entId,OrchestratorId)
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +

we assume the authz request sent by "Client&= quot; to "AS" describes the protected resource without referring= =C2=A0to the authz server. An AS can issue the authz to release the graduat= ion record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,StudentId,Orchestr= atorId]), without any reference to the target university.=C2=A0

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource s= erver.
- RecordType: a reference = to a resource of type graduation record as understandable=C2=A0 by the reso= urce server.
-=C2=A0OrchestratorI= d: reference to the Orchestrator. Can be used to bind authz to Orchestrator= .

But:
- RS must tr= ust AS issued token.
-=C2=A0Stude= ntId must be known to RS, AS and=C2=A0Orchestrator.

Therefore= , the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.
<= font face=3D"monospace">
What= privacy problem do you see here?

Best regards.
<= div>/Francis

On Tue, Aug 4, 2020 at 5:= 08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000005688b405aca19383-- From nobody Tue Aug 11 15:37:36 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 D45C23A0D64 for ; Tue, 11 Aug 2020 15:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 QmvZOrA81mNn for ; Tue, 11 Aug 2020 15:37:31 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 413F23A0D58 for ; Tue, 11 Aug 2020 15:37:31 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a5so254150wrm.6 for ; Tue, 11 Aug 2020 15:37:31 -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=g2MPsoqTjpfBoOsQtYc3IFZ4twYByga6JHYGtCacRD8=; b=hesTtHGXzSWzn68wRAZ41dfALeJsrXojPyNkxw0FFzdc0O9JxQvX75kkADcPQRjEA8 KE7remv/A/LeEo+v/ZubvXVvlQnbkv4RNS3ZHVIaajoztIVs0bHiaW29M1juDNosFUyQ j1Oqh0p4W3I5C7H90FuI+Wbg6A9qGtnmTo7WI= 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=g2MPsoqTjpfBoOsQtYc3IFZ4twYByga6JHYGtCacRD8=; b=buApCMUvunzDp2aYBt1xvNxtSVTIM8TRBgrno9w7HG1xLCKwuBR5Q6kMl8hpHBjDEc folohvYL7YRsHXkri66Cwy7FSm7K/CrgFA+Kwy6U4zQqWWlbJoqTcFxW1Bn4MiGUCn8p FZX27F2IPQEjJcQLK4HcLFJx4es9n/VwsSV8ZymGLKtB2uEjcFPDmA1LjWmSTtREY3Ru si8ReARHYlnEziB+l0fzD4SdJNyuZ5KXAsgIHDpIgXd8VABISApVEKXLOgw/GLcppeg9 wp/KJD6G0zRDPs3gvkVZWrK9Q+r4CtIFhdhDDc95NAy4k5Kp2Myu1DvQQ/qsE5oHEpjP T/rA== X-Gm-Message-State: AOAM532gjyKVwQ3EJga4yuzeY52xGGU2KguLp1nd6uAy9OY+1tTeW5FA 4VJFiRCehlgMz55Vbb3we58qxIEQFWuRBqpWMqS3tw== X-Google-Smtp-Source: ABdhPJx6mV4NvR4TtmmxULTveEMpnFwOzvsAJf3eGynDFl2L67ocfTDq1KMgAmh43RbEMriF2zE+7kYHB3M6Q3BLuC8= X-Received: by 2002:a5d:4a41:: with SMTP id v1mr33742114wrs.371.1597185444450; Tue, 11 Aug 2020 15:37:24 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 18:37:13 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000eaede05aca1b791" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 11 Aug 2020 22:37:35 -0000 --0000000000000eaede05aca1b791 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dick, On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt wrote: > Hi Francis > > The user is an entity, not a role in the protocol in how I am defining > roles, so steps (1) and (7) are confusing to me on what is happening. > "Requestor" is the role (*was* User). So the UML participant refers to the role "Requestor" > I also think that (2) could be an extension to GNAP, rather than part of > the core protocol. > If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol. If the "Orchestrator/Negotiator/Client" can translate the service request into a resource request, then there will be no need to invoke (2). When we move beyond identity management, cases become complex and it makes sense to explicitly display this possibility in the protocol flow. In some open banking designs, - the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2). - the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6). /Francis > > > > > > On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha wrote: > >> In this context, I suggest we pick some words to work with, and sharpen >> them as we move on, discover and map new use cases to the protocol. >> >> In this diagram from the original thread ( >> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw= /), >> I replaced the words: >> >> +-----------+ +--------------+ +----+ +----+ >> +---------------------+ >> | Requestor | | Orchestrator | | | | GS | | Resource >> Controller | >> | was | | was | | RS | | or | | was >> | >> | User | | Client | | | | AS | | Resource Owner >> | >> +-----------+ +--------------+ +----+ +----+ >> +---------------------+ >> |(1) ServiceRequest | | | | >> |---------------------->| | | | >> | |(2) ServiceIntent:AuthZChallenge | >> | |<---------->| | | >> | | | | | >> | |(3) AuthZRequest(AuthZChallenge) | >> | |------------------->| | >> | | | |(4) ConsentRequest:Grant >> | | | |<-------------->| >> | |(5) GrantAccess(AuthZ) | >> | |<-------------------| | >> | | | | | >> | |(6) ServiceRequest(AuthZ):ServiceResponse >> | |<---------->| | | >> |(7) ServiceResponse | | | | >> |<----------------------| | | | >> + + + + + >> >> The purpose of the GNAP protocol is to help negotiate access to a >> protected resource. It starts with a requestor delegating activity to an >> orchestrator. These are all roles, no entities. Let focus on mapping the >> use cases to the protocol roles and interactions so wwe can discover wha= t >> is missing. >> >> It seems cumbersome to use it in discussions as it is impossible to give >> the word "Client" a clear definition. >> >> We can mention in the final document, that the "Orchestrator" (or >> whatever word we finally use) plays the same role as the "Client" in oAu= th2. >> >> Best regards. >> /Francis >> >> >> >> >> >> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt wrote: >> >>> I agree with Justin. Redefining well used terms will lead to significan= t >>> confusion. If we have a different role than what we have had in the pas= t, >>> then that role should have a name not being used already in OAuth or OI= DC. >>> >>> Given what we have learned, and my own experience explaining what a >>> Client is, and is not, improving the definition for Client could prove >>> useful. I am not suggesting the term be redefined, but clarified. >>> >>> For example, clarifying that a Client is a role an entity plays in the >>> protocol, and that the same entity may play other roles at other times,= or >>> some other language to help differentiate between "role" and "entity". >>> >>> /Dick >>> =E1=90=A7 >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >> > wrote: >>> >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bet= ter fit, but I=E2=80=99m >>>> not really in favor of taking an existing term and applying a complete= ly >>>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>>> and come up with a new, more specific and accurate term for the role t= han >>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely dif= ferent. We did this >>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserve= r=E2=80=9D on its own but instead >>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>> >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is >>>> ignore the fact that GNAP is going to be coming up in a world that is >>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t ha= ve a blank >>>> slate to work with, but neither are we bound to use the same terms and >>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>> >>>> I think that is fundamentally part of the question: >>>> >>>>> We are clear that we are producing a protocol that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion >>>> >>>> >>>> If we say that this document assumes OAuth2.0 terminology, then we >>>> should not change the meanings of any definition. If we are saying thi= s >>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the= best >>>> word for the job and ignore conflicting meanings from OAuth 2.0. I hav= e a >>>> lot of first hand experience of industries "ruining words", and attemp= ting >>>> to side-step the problem rather than redefining the word just confuses >>>> everyone as everyone forgets the original meaning as new documents com= e >>>> out, but the confusion with the use of a non-obvious word continues. >>>> >>>> Food for thought. >>>> - Warren >>>> >>>> Warren Parad >>>> Founder, CTO >>>> Secure your user data and complete your authorization architecture. >>>> Implement Authress . >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>> >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a response similar to th= e >>>>> one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there=E2=80=99s still a problem with the terminology in u= se here. >>>>> What >>>>> > > you describe as RS2, which might in fact be an RS unto itself, is >>>>> a >>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What >>>>> you >>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not >>>>> at >>>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>>> > > entities below, but it makes it difficult to hold a discussion if >>>>> we >>>>> > > aren=E2=80=99t using the same terms. >>>>> > > >>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can >>>>> define >>>>> > > our own terms. The bad news is that this is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>>> definitions, >>>>> > > but we=E2=80=99ve got a chance to be more precise with how we def= ine >>>>> things. >>>>> > >>>>> > In the ISO context, each document must define its own terminology. >>>>> The >>>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>>> section >>>>> > but does not prevent it either. The vocabulary is limited and as >>>>> long as >>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>> already >>>>> > used in another RFC. This is also the ISO approach. >>>>> >>>>> Just because we can do something does not necessarily mean that it is= a >>>>> good idea to do so. We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>> Dick to >>>>> use the term "GS" in XAuth, picking a name that was not already used = in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> 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/ >> > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000000eaede05aca1b791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dick,

On Tue, Aug 11, 202= 0 at 6:22 PM Dick Hardt <dick.ha= rdt@gmail.com> wrote:
Hi Francis

The user is an = entity, not a role in the protocol in how I am defining roles, so steps (1)= and (7) are confusing to me on what is happening.
=
"Requestor" is the role (was User). So the UML partic= ipant refers=C2=A0to the role "Requestor"


I also think that (2) could be an extension to GNAP, rather than p= art of the core protocol.
If you make it an ex= tension, you hide. It shall rather be an optional, integral part of the pro= tocol. If the "Orchestrator/Negotiator/Client" can translate the = service request into a resource request, then there will be no need to invo= ke (2).

When we move beyond identity management, c= ases become complex and it makes sense to explicitly display this possibili= ty in the protocol flow.

In some open banking desi= gns,=C2=A0
- the "Orchestrator/Negotiator/Client" will = not know the AS to talk to unless the call (2).
- the request (2)= might result in an exemption, meaning no need for further authorization, a= llowing to skip (3, 4, 5) and even (6).

/Francis





On Mon, Aug 10, 202= 0 at 8:04 PM Francis Pouatcha <fpo@adorsys.de> wrote:
In this= context, I suggest we pick some words to work with, and sharpen them as we= move on, discover and map new use cases to the protocol.

In this d= iagram from the original thread (https:= //mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 = +--------------+ =C2=A0+----+ =C2=A0+----+ =C2=A0+---------------------+| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0 =C2=A0 | = =C2=A0| GS | =C2=A0| Resource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0RS=C2=A0|=C2=A0 |= =C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|
|=C2=A0 User=C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 = =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 Resou= rce Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +-------------= -+ =C2=A0+----+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) S= erviceRequest=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZCh= allenge=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 = =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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) ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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) Gran= tAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ)= :ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the G= NAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating a= ctivity to an orchestrator. These are all roles, no entities. Let focus on = mapping the use cases to the protocol roles and interactions so wwe can dis= cover what is missing.

It seems cum= bersome to use it in discussions as it is impossible to give the word "= ;Client" a clear definition.

W= e can mention=C2=A0in the final document, that the "Orchestrator"= (or whatever word we finally use) plays the same role as the "Client&= quot; in oAuth2.
Best regards.
/Francis

<= br>



On Wed, Aug 5, 2020 at 9:05 P= M Dick Hardt <= dick.hardt@gmail.com> wrote:
I agree with Justin. Redefining well u= sed terms will lead to significant confusion. If we have a different role t= han what we have had in=C2=A0the past, then that role should have a name no= t being used already in OAuth or OIDC.

Given what we hav= e learned, and my own experience explaining what a Client is, and is not, i= mproving the definition for Client could prove useful. I am not suggesting = the term be redefined, but clarified.=C2=A0

For ex= ample, clarifying that a Client is a role an entity plays in the protocol, = and that the same entity may play other roles at other times, or some other= language to help differentiate between "role" and "entity&q= uot;.

/Dick
3D""=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I=E2=80=99m in favor of= coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m not= really in favor of taking an existing term and applying a completely new d= efinition to it. In other words, I would sooner stop using =E2=80=9Cclient= =E2=80=9D and come up with a new, more specific and accurate term for the r= ole than to define =E2=80=9Cclient=E2=80=9D as meaning something completely= different. We did this in going from OAuth 1 to OAuth 2 already, moving fr= om the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D= at all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead al= ways qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9C= Resource Server=E2=80=9D.

GNAP can do something similar,= in my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP i= s going to be coming up in a world that is already permeated =C2=A0by OAuth= 2 and its terminology. We don=E2=80=99t have a blank slate to work with, b= ut neither are we bound to use the same terms and constructs as before. It= =E2=80=99s going to be a delicate balance!

=C2=A0= =E2=80=94 Justin

On = Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to = OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitio= ns may lead to unnecessary
confusion

If = we say that this document assumes OAuth2.0 terminology, then we should not = change the meanings of any definition. If we are saying this supersedes or = replaces what OAuth 2.0 creates, then we should pick the best word for the = job and ignore conflicting meanings from OAuth 2.0. I have a lot of first h= and experience of industries "ruining words", and attempting to s= ide-step the problem rather than redefining the word just confuses everyone= as everyone forgets the original meaning as new documents come out, but th= e confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

Warren Parad
= Founder, CTO
Secure your user data and complete your authorization arch= itecture. Implement=C2=A0Authress.


On Tue, Aug 4, 2020 at 8:53 P= M Benjamin Kaduk <kad= uk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
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
https://= adorsys-platform.de/solutions/
--0000000000000eaede05aca1b791-- From nobody Tue Aug 11 15:40:23 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 027DF3A0D66 for ; Tue, 11 Aug 2020 15:40:21 -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 ky6UHzEgu8Kh for ; Tue, 11 Aug 2020 15:40:17 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 CA1EF3A0B34 for ; Tue, 11 Aug 2020 15:40:16 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id 88so271278wrh.3 for ; Tue, 11 Aug 2020 15:40:16 -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=2sdU3XB5tPxMH/5JexTOzzcgrgz5zLizkLe+RWxSMhA=; b=ckxVXgG1+DVX6Ng+ViYlnlBceov/Aj5AVaW9XWX58oqlXN6RdqdCfXeOBNyqM4+Wui 6/4iHAqcTm+McNHfgSi25YwbtbphEAzsDQd2wlKMNCB2GWKOEYq7+jvfIgFIli4BkOTJ qQJJq/EF77i3LpqqIj5p8k+853A7ML7EDD4AY= 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=2sdU3XB5tPxMH/5JexTOzzcgrgz5zLizkLe+RWxSMhA=; b=RdkAgmCjUvs1+XxfDJJfyQmCLRZnKDNnNV6bZ4HP9G7EeGSzbMP2YEk59N4tnwJl8c R64h5CmqF+WHe//rJTR+x6iTXKS1l9qPe4Akof3oN3FAWjellzKrecKn2CvDv7yjh1Rb l9Ym4A/AEEN6NzaVHcO+PGtmzyRSzewPUsQxvTtpwoZ+8476x+hi0wYvHC/1kE60mTZJ Dk8h8jV94ygW/gLx0ROW9g8A3humNLaYAECNVdtxMtegRrsD8+OAIFpvOdd59ThWcRgO qAH1qSvu3HhepB37dQ2deT3mxQzmIwpBr3x/uGf4G+L6aD32+zP9FWHew1Tt97lA3Tms gPLw== X-Gm-Message-State: AOAM533dX9ZHJ3TKsGkjin8O6oIKupRGlh5+/4AILT3wgwZ3twV7ntNa Anke0rEWNA6jXIwu3pLY8lcOy35z3N0tZlvYCqmXOg== X-Google-Smtp-Source: ABdhPJzsJdsjVTXGll5kI14nSsWXXxl+LLGNVq/WpGPBmpb3tMOGZhhycKkEJqIB1o3AIqo0jbyDmeTXug1/Qepj7SI= X-Received: by 2002:a5d:45c9:: with SMTP id b9mr30359282wrs.283.1597185615129; Tue, 11 Aug 2020 15:40:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 18:40:04 -0400 Message-ID: To: Tom Jones Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003b043b05aca1c118" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 22:40:21 -0000 --0000000000003b043b05aca1c118 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 11, 2020 at 6:27 PM Tom Jones wrote: > "The token request must not mention any reference of the RS." > this cannot be an absolute rule. I have cases were the client needs to > tell the user which they are coming back for additional grants. > The reason is typically because a request by the client for data/access > from the rs was rejected. The reason for the rejection is important for t= he > client to make the case to the user for additional permissions. > Peace ..tom > - If you want privacy, *don't* expose RS identity to AS. - If you want transparency, expose RS identity to AS. You can't have both.... /Francis > > > > On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha 40adorsys.de@dmarc.ietf.org> wrote: > >> Hello Fabian, >> >> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault >> wrote: >> >>> Hi Francis, >>> >>> I think Denis points to the fact that, in the current situation, the AS >>> receives the resource request from the Client and therefore knows what >>> tokens are asked. >>> >> The token request must not mention any reference of the RS. >> >> >>> Then it also implements the consent interface (and possibly the login >>> too) and so it also knows who validates and what is accepted or not. >>> >> Decoupling this does not change the privacy context, as the AS issues th= e >> Token. AS needs to add a reference to the RC in the token. SO AS can >> correlate on StudentId anyway. >> >> >>> I don't think the abstract flow deals with those privacy concerns. >>> >> To solve the privacy problem addressed in this thread, we need to go the >> (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a V= C >> (Verifiable Credential) to the Student (in his role of RC). The Student >> will then present this claim to UNIV-1 during his registration. In this >> case we need no Grant negotiation and no AS. >> >> Best regards. >> /Francis >> >>> >> >>> >>> Then I agree with you on the audience field of the token, if left empty >>> it simplifies part of the problem, although it removes a big part of th= e >>> control you may want from directed tokens. That's why I'm willing to be= tter >>> develop the RS hiding idea. >>> >>> Fabien >>> >>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>> >>>> Hello Denis, >>>> >>>> what you describe in the use case seems to be the default behavior of >>>> the protocol. Let me map it with this abstract protocol flow: >>>> >>>> +-----------+ +--------------+ +-----------+ +----+ >>>> +---------------------+ >>>> | Requestor | | Orchestrator | | RS | | GS | | Resource >>>> Controller | >>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>> is | >>>> | Staff | | Registr. App | | Server | | AS | | >>>> Student | >>>> +-----------+ +--------------+ +-----------+ +----+ >>>> +---------------------+ >>>> |(1) RegisterStudent | | | >>>> | >>>> |---------------------->| | | >>>> | >>>> | |(2) RequestRecordIntent(RecordType,StudentI= d, >>>> | | >>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>> | |<-------------->| | >>>> | >>>> | | | | >>>> | >>>> | |(3) >>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>> | |--------------------------->| >>>> | >>>> | | | |(4) >>>> ConsentRequest(RecordType, >>>> | | | | >>>> OrchestratorId):Consent >>>> | | | >>>> |<-------------->| >>>> | >>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>> | |<---------------------------| >>>> | >>>> | | | | >>>> | >>>> | |(2) >>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>> | | :RecordOf[StudentId] | >>>> | >>>> | |<-------------->| | >>>> | >>>> |(7) Registered | | | >>>> | >>>> |<----------------------| | | >>>> | >>>> + + + + >>>> + >>>> >>>> we assume the authz request sent by "Client" to "AS" describes the >>>> protected resource without referring to the authz server. An AS can is= sue >>>> the authz to release the graduation record of a student >>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any referenc= e to >>>> the target university. >>>> >>>> What matters for this authz object is: >>>> - StudentId: a reference to the student as known to the resource serve= r. >>>> - RecordType: a reference to a resource of type graduation record as >>>> understandable by the resource server. >>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>> authz to Orchestrator.. >>>> >>>> But: >>>> - RS must trust AS issued token. >>>> - StudentId must be known to RS, AS and Orchestrator. >>>> >>>> Therefore, the AS does not need to know the RS. Keep the audience fiel= d >>>> empty. >>>> >>>> Same principle applies for the second use case. >>>> >>>> What privacy problem do you see here? >>>> >>>> Best regards. >>>> /Francis >>>> >>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>> >>>>> I tried my best twice to download three use cases in the Use cases >>>>> directory, but I failed. >>>>> >>>>> Rather than failing a third time, here is the direct link of the >>>>> second try: >>>>> >>>>> >>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-= cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>> >>>>> Denis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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/ >>>> -- >>>> 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/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000003b043b05aca1c118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 11, 2020 at 6:27 PM Tom Jones= <thomasclinganjones@gma= il.com> wrote:
"The token request must not mention any reference o= f the RS."
this cannot be an absolute rule. I have cases wer= e the client needs to tell the user which they are coming back for addition= al grants.
The reason is typically because a request by the clien= t for data/access from the rs was rejected. The reason for the rejection is= important for the client to make the case to the user for additional permi= ssions.
Peace ..tom
- If you want privacy, don't expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can&= #39;t have both....
/Francis=C2=A0



On Tue, Aug 11, 2020 at 2= :27 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <<= a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault= @gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation,= the AS receives the resource request from the Client and therefore knows w= hat tokens are asked.
The token request must = not mention any reference of the RS.
=C2=A0
Then = it also implements the consent interface (and possibly the login too) and s= o it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS= issues the Token. AS needs to add a reference to the=C2=A0RC in the token.= SO AS can correlate on StudentId anyway.

I don't think the abstract flow deals with th= ose privacy concerns.=C2=A0
To solve the priva= cy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Th= en UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credentia= l) to the Student (in his role of RC). The Student will then present this c= laim to UNIV-1 during his registration. In this case we need no Grant negot= iation and=C2=A0no AS.

Best regards.
/Fr= ancis
=C2=A0

Then I agree with you on the audience field of the token, if le= ft empty it simplifies part of the problem, although it removes a big part = of the control you may want from directed tokens. That's why I'm wi= lling to better develop the RS hiding idea.=C2=A0
Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3= =A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> a =C3=A9cri= t=C2=A0:
Hello=C2=A0Denis,

what you describe in the use= case seems to be the default behavior of the protocol. Let me map it with = this abstract protocol flow:

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+--------= ---+ =C2=A0+----+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2= =A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|= =C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Reg= istr. App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2= =A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+= ---------------------+
=C2=A0 |(1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) R= equestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest[Re= cordType,StudentId]
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(RecordType,StudentId,Or= chestratorId)
=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-= -------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentReq= uest(RecordType,
=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<-------------->|
=C2=A0 |=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=A0AuthZ[RecordT= ype,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------------------= ------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|(2) RequestRecord(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[St= udentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= -------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

we assume the auth= z request sent by "Client" to "AS" describes the protec= ted resource without referring=C2=A0to the authz server. An AS can issue th= e authz to release the graduation record=C2=A0 of a student ((5)=C2=A0AuthZ= [RecordType,StudentId,OrchestratorId]), without any reference to the target= university.=C2=A0

What matters for this authz object is:
- StudentId: a reference to the stud= ent as known to the resource server.
- RecordType: a reference to a resource of type graduation record as un= derstandable=C2=A0 by the resource server.
-=C2=A0OrchestratorId: reference to the Orchestrator. Can be used= to bind authz to Orchestrator..
=
But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2=A0Orches= trator.

Therefore, the AS does not need to know the RS. Keep = the audience field empty.

Same principle applies for the seco= nd use case.

What privacy problem do you see here?

Best regards.
/Francis=

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> w= rote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
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/
--0000000000003b043b05aca1c118-- From nobody Tue Aug 11 15:43:10 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 1E1A13A0E11 for ; Tue, 11 Aug 2020 15:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 ysDKmpgWmdYq for ; Tue, 11 Aug 2020 15:42:59 -0700 (PDT) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 91EC43A0DBD for ; Tue, 11 Aug 2020 15:42:59 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id j19so72473oor.2 for ; Tue, 11 Aug 2020 15:42: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=K8zOZ8zdDw29axLCsBTbq4dPXMJRocUfOJ5wrK2WoHw=; b=tuwah/mwg7VGgktNexjN8F/+Gj8ax58FsHhLo1BZpfen3OozbTjC9s9u0OOgr0y7Oy TC8bj2qmCxWgAjfnz1Orn7SSJeVbKCFylTGC4NhE+V4VnTe353dILTjSuhh2zKcAB9ON Y9qaOlt8tIjoZHuGjvxPDIpO0WLJRWLsI6DHqXfdXvaJl6zXLgC9S2h1kO5Dx5aVDX4l +k7xh6cnjzag3TNnu+y/JVWXky40wY95ib4mLJz7VORaL5o7jk8NsJLryqWsuR4j9qxk nhlysNtNp7pq6TZ8CW4LRQAg3BM+NPaMfw7T0/qJwpomxnYyF/S8Jq8G70qDTZgZbcfT eK0Q== 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=K8zOZ8zdDw29axLCsBTbq4dPXMJRocUfOJ5wrK2WoHw=; b=jfun97nbu48J0Ud1RalmobCuAZHSK0eZ83iVZUT5rJXsQFYA7IsHcuXJ48aqE02Ltr JZzw0ZocFQoD3Z36tt3OU5xLuzeN8VKXe9lwm5EZczKy0YuxGO9s+y2YHvuZ7ZHKpLgW IGiDOnklAir79znoDTRunJeETmDHOkytOOx4xtNaPEWmDoJ210q9SuOiDmRvhOpYntI6 k3WRryxqXUsYjxVb05ct+Q34Jlh4oyaE1ZZZENlG0HB5b25wvqQnZXXpaBi3O2sEMSPi JK3pj8vuM4sioeAhg6TVm6fwCx/ZMsDhlsRI84P39//kc2Q/2KT8sCHmmvd61+44T635 nt/Q== X-Gm-Message-State: AOAM531ekLroxy+BVAcfexwFjPNUANWpKO7CIP9MKW/5qmMDN+u715EF 2uNDCp1enaH7GBA3qnUGC/35xzNaeeRfnxnY5gM= X-Google-Smtp-Source: ABdhPJx6XYVAS1q3pT8rXlpRFw0afpuUp59xgznS9EjbHVggB+XG0Eb4vPQhEA9qvqxv7fHEOlj8/pRZql53u8ZQmVw= X-Received: by 2002:a4a:aa0e:: with SMTP id x14mr7174404oom.27.1597185778623; Tue, 11 Aug 2020 15:42:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Tue, 11 Aug 2020 15:42:47 -0700 Message-ID: To: Francis Pouatcha Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f9a7ef05aca1cab7" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 22:43:09 -0000 --000000000000f9a7ef05aca1cab7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I guess I need to ask the group as a whole then. Will GNAP support self-issued Identifiers? If so then the AS is on the user's device. I need to understand that SII are in-scope. Peace ..tom On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha wrote: > On Tue, Aug 11, 2020 at 6:27 PM Tom Jones > wrote: > >> "The token request must not mention any reference of the RS." >> this cannot be an absolute rule. I have cases were the client needs to >> tell the user which they are coming back for additional grants. >> The reason is typically because a request by the client for data/access >> from the rs was rejected. The reason for the rejection is important for = the >> client to make the case to the user for additional permissions. >> Peace ..tom >> > - If you want privacy, *don't* expose RS identity to AS. > - If you want transparency, expose RS identity to AS. > You can't have both.... > /Francis > >> >> >> >> On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> wrote: >> >>> Hello Fabian, >>> >>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> I think Denis points to the fact that, in the current situation, the A= S >>>> receives the resource request from the Client and therefore knows what >>>> tokens are asked. >>>> >>> The token request must not mention any reference of the RS. >>> >>> >>>> Then it also implements the consent interface (and possibly the login >>>> too) and so it also knows who validates and what is accepted or not. >>>> >>> Decoupling this does not change the privacy context, as the AS issues >>> the Token. AS needs to add a reference to the RC in the token. SO AS ca= n >>> correlate on StudentId anyway. >>> >>> >>>> I don't think the abstract flow deals with those privacy concerns. >>>> >>> To solve the privacy problem addressed in this thread, we need to go th= e >>> (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a = VC >>> (Verifiable Credential) to the Student (in his role of RC). The Student >>> will then present this claim to UNIV-1 during his registration. In this >>> case we need no Grant negotiation and no AS. >>> >>> Best regards. >>> /Francis >>> >>>> >>> >>>> >>>> Then I agree with you on the audience field of the token, if left empt= y >>>> it simplifies part of the problem, although it removes a big part of t= he >>>> control you may want from directed tokens. That's why I'm willing to b= etter >>>> develop the RS hiding idea. >>>> >>>> Fabien >>>> >>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>> >>>>> Hello Denis, >>>>> >>>>> what you describe in the use case seems to be the default behavior of >>>>> the protocol. Let me map it with this abstract protocol flow: >>>>> >>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>> +---------------------+ >>>>> | Requestor | | Orchestrator | | RS | | GS | | Resourc= e >>>>> Controller | >>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>> is | >>>>> | Staff | | Registr. App | | Server | | AS | | >>>>> Student | >>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>> +---------------------+ >>>>> |(1) RegisterStudent | | | >>>>> | >>>>> |---------------------->| | | >>>>> | >>>>> | |(2) >>>>> RequestRecordIntent(RecordType,StudentId, >>>>> | | >>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>> | |<-------------->| | >>>>> | >>>>> | | | | >>>>> | >>>>> | |(3) >>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>> | |--------------------------->| >>>>> | >>>>> | | | |(4) >>>>> ConsentRequest(RecordType, >>>>> | | | | >>>>> OrchestratorId):Consent >>>>> | | | >>>>> |<-------------->| >>>>> | >>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>> | |<---------------------------| >>>>> | >>>>> | | | | >>>>> | >>>>> | |(2) >>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>> | | :RecordOf[StudentId] | >>>>> | >>>>> | |<-------------->| | >>>>> | >>>>> |(7) Registered | | | >>>>> | >>>>> |<----------------------| | | >>>>> | >>>>> + + + + >>>>> + >>>>> >>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>> protected resource without referring to the authz server. An AS can i= ssue >>>>> the authz to release the graduation record of a student >>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any referen= ce to >>>>> the target university. >>>>> >>>>> What matters for this authz object is: >>>>> - StudentId: a reference to the student as known to the resource >>>>> server. >>>>> - RecordType: a reference to a resource of type graduation record as >>>>> understandable by the resource server. >>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>>> authz to Orchestrator.. >>>>> >>>>> But: >>>>> - RS must trust AS issued token. >>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>> >>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>> field empty. >>>>> >>>>> Same principle applies for the second use case. >>>>> >>>>> What privacy problem do you see here? >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>> >>>>>> I tried my best twice to download three use cases in the Use cases >>>>>> directory, but I failed. >>>>>> >>>>>> Rather than failing a third time, here is the direct link of the >>>>>> second try: >>>>>> >>>>>> >>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use= -cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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/ >>>>> -- >>>>> 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/ >>> -- >>> 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/ > --000000000000f9a7ef05aca1cab7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess I need to ask the group as a whole then.
Will = GNAP support self-issued Identifiers?
If so then the AS is on the= user's device.
I need to understand that SII are in-scope.
Peace ..tom
=


On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha <fpo@adorsys.de> wrote:
On Tue, Aug 11, 2020 at 6:27 PM Tom Jones <thomasclinganjones@gmail.com> = wrote:
<= div>"The token request must not mention any reference of the RS."=
this cannot be an absolute rule. I have cases were the client ne= eds to tell the user which they are coming back for additional grants.
The reason is typically because a request by the client for data/acce= ss from the rs was rejected. The reason for the rejection is important for = the client to make the case to the user for additional permissions.
Peace ..tom
- If you want= privacy, don't expose RS identity to AS.
- If you wan= t transparency, expose RS identity to AS.
You can't have both= ....
/Francis=C2=A0



On Tue, Aug 11, 2020 at 2:27 PM Francis= Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:


=C2=A0

= Then I agree with you on the audience field of the token, if left empty it = simplifies part of the problem, although it removes a big part of the contr= ol you may want from directed tokens. That's why I'm willing to bet= ter develop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Fra= ncis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> a =C3=A9crit=C2=A0:
Hell= o=C2=A0Denis,

what you describe in the use case seems to= be the default behavior of the protocol. Let me map it with this abstract = protocol flow:

+----= -------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+--= --+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Or= chestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2= =A0| Resource Controller |
| is U= NIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is= UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2= =A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2= =A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+--------------= -------+
=C2=A0 |(1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |--= -------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIn= tent(RecordType,StudentId,
=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest[RecordType,Stude= ntId]
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----= ---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-------------------= -------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----------= ---->|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,Orchest= ratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(R= ecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 += =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +

we assume the authz request sent by= "Client" to "AS" describes the protected resource with= out referring=C2=A0to the authz server. An AS can issue the authz to releas= e the graduation record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,Stude= ntId,OrchestratorId]), without any reference to the target university.=C2= =A0

What matters for this authz object is:
<= font face=3D"monospace">- StudentId: a reference to the student as known to= the resource server.
- RecordTyp= e: a reference to a resource of type graduation record as understandable=C2= =A0 by the resource server.
-=C2= =A0OrchestratorId: reference to the Orchestrator. Can be used to bind authz= to Orchestrator..

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2=A0Orchestrator.=

Therefore, the AS does not need to know the RS. Keep the audience f= ield empty.

Same principle applies for the second use case.

What privacy problem do you see here?

Best reg= ards.
/Francis
=
On Tue= , Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


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


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--000000000000f9a7ef05aca1cab7-- From nobody Tue Aug 11 15:47:42 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 86FD33A0D84 for ; Tue, 11 Aug 2020 15:47:40 -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 v2owTs5yrB23 for ; Tue, 11 Aug 2020 15:47:38 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 07D643A0D75 for ; Tue, 11 Aug 2020 15:47:37 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 9so175867wmj.5 for ; Tue, 11 Aug 2020 15:47:37 -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=qnhlk+ic5O5aRXm/WSXTCAUtnVa8m+cGrK5fiNA1T7g=; b=Z4x/gYiN8Re6rxdN21KUEsIk+Q1nw8fZYyFefPIXTrPoDfjQ/bwkfoTZb5PW4l1RCY XvmWw2En3ZfIcsM24q1cV1K0JrKAuRNg2DvJ6HR2MvQv7kxXq0gJDdUBFOqmgXCXze1P /1DuCTpRC8bPYu3GVq6/E7bBNSMyt00xbeOLc= 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=qnhlk+ic5O5aRXm/WSXTCAUtnVa8m+cGrK5fiNA1T7g=; b=UnYaYPcriHFpxRNckGvV4o9ckwahQVMeg/jeGU+5n0MGwx7d0jGg3F1SqlnQpQMVKn PzAGEUP661jVio6K4CW2PlTxXsvbpaGg3awrRgtcrtUgMVR6J1CczsvLkDdCaKvHh+r4 cEtXgprXZmCW3ZdgJRk/2E2s4Vw0gFeF+O+jucG2TbX4Dh0dkn4RHPFBBeHRxqret1Yo cS0O6quSJIclOh57HJYjNinKaOHZ4irx2ndVMWyypsI/LPIJg8Mh6wsSyo0dxg+5+Fgy Z6qUPcc6tFvigUDI314qnJ0CkA/K/C9r88+hTleU8ReRkWX7jhT/fauqGPmXzi3yQGv/ G9Qg== X-Gm-Message-State: AOAM5314OTFOzAWHs3O3uC+pmSBtNDgJ+0nTvBN91vrfb6Kz/Gv/Mdjf Ps93LwY5KSBdzNAl9hzEaabGq9EHh2MPSYKuqmGL3A== X-Google-Smtp-Source: ABdhPJw8gllFPL0m51YKYoZHeBwzz+5btrROxfgaxbOmQI/YQywzz6upc6jTfExVeOGq6ToQPciEjN32gZXOICUbC8U= X-Received: by 2002:a1c:3985:: with SMTP id g127mr5435429wma.64.1597186056372; Tue, 11 Aug 2020 15:47:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 18:47:25 -0400 Message-ID: To: Tom Jones Cc: Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000087d7e105aca1db0b" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 22:47:41 -0000 --00000000000087d7e105aca1db0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Tom, On Tue, Aug 11, 2020 at 6:42 PM Tom Jones wrote: > I guess I need to ask the group as a whole then. > Will GNAP support self-issued Identifiers? > If so then the AS is on the user's device. > I need to understand that SII are in-scope. > Peace ..tom > I hope GNAP will be designed to support SII. If you could drop some use cases here: https://github.com/ietf-wg-gnap/general/wiki > > > On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha wrote: > >> On Tue, Aug 11, 2020 at 6:27 PM Tom Jones >> wrote: >> >>> "The token request must not mention any reference of the RS." >>> this cannot be an absolute rule. I have cases were the client needs to >>> tell the user which they are coming back for additional grants. >>> The reason is typically because a request by the client for data/access >>> from the rs was rejected. The reason for the rejection is important for= the >>> client to make the case to the user for additional permissions. >>> Peace ..tom >>> >> - If you want privacy, *don't* expose RS identity to AS. >> - If you want transparency, expose RS identity to AS. >> You can't have both.... >> /Francis >> >>> >>> >>> >>> On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> wrote: >>> >>>> Hello Fabian, >>>> >>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Francis, >>>>> >>>>> I think Denis points to the fact that, in the current situation, the >>>>> AS receives the resource request from the Client and therefore knows = what >>>>> tokens are asked. >>>>> >>>> The token request must not mention any reference of the RS. >>>> >>>> >>>>> Then it also implements the consent interface (and possibly the login >>>>> too) and so it also knows who validates and what is accepted or not. >>>>> >>>> Decoupling this does not change the privacy context, as the AS issues >>>> the Token. AS needs to add a reference to the RC in the token. SO AS c= an >>>> correlate on StudentId anyway. >>>> >>>> >>>>> I don't think the abstract flow deals with those privacy concerns. >>>>> >>>> To solve the privacy problem addressed in this thread, we need to go >>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to iss= ue a >>>> VC (Verifiable Credential) to the Student (in his role of RC). The Stu= dent >>>> will then present this claim to UNIV-1 during his registration. In thi= s >>>> case we need no Grant negotiation and no AS. >>>> >>>> Best regards. >>>> /Francis >>>> >>>>> >>>> >>>>> >>>>> Then I agree with you on the audience field of the token, if left >>>>> empty it simplifies part of the problem, although it removes a big pa= rt of >>>>> the control you may want from directed tokens. That's why I'm willing= to >>>>> better develop the RS hiding idea. >>>>> >>>>> Fabien >>>>> >>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>> >>>>>> Hello Denis, >>>>>> >>>>>> what you describe in the use case seems to be the default behavior o= f >>>>>> the protocol. Let me map it with this abstract protocol flow: >>>>>> >>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>> +---------------------+ >>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>> Resource Controller | >>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>> is | >>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>> Student | >>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>> +---------------------+ >>>>>> |(1) RegisterStudent | | | >>>>>> | >>>>>> |---------------------->| | | >>>>>> | >>>>>> | |(2) >>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>> | | >>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>> | |<-------------->| | >>>>>> | >>>>>> | | | | >>>>>> | >>>>>> | |(3) >>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>> | |--------------------------->| >>>>>> | >>>>>> | | | |(4) >>>>>> ConsentRequest(RecordType, >>>>>> | | | | >>>>>> OrchestratorId):Consent >>>>>> | | | >>>>>> |<-------------->| >>>>>> | >>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>> | |<---------------------------| >>>>>> | >>>>>> | | | | >>>>>> | >>>>>> | |(2) >>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>> | | :RecordOf[StudentId] | >>>>>> | >>>>>> | |<-------------->| | >>>>>> | >>>>>> |(7) Registered | | | >>>>>> | >>>>>> |<----------------------| | | >>>>>> | >>>>>> + + + + >>>>>> + >>>>>> >>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>> protected resource without referring to the authz server. An AS can = issue >>>>>> the authz to release the graduation record of a student >>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refere= nce to >>>>>> the target university. >>>>>> >>>>>> What matters for this authz object is: >>>>>> - StudentId: a reference to the student as known to the resource >>>>>> server. >>>>>> - RecordType: a reference to a resource of type graduation record as >>>>>> understandable by the resource server. >>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>>>> authz to Orchestrator.. >>>>>> >>>>>> But: >>>>>> - RS must trust AS issued token. >>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>> >>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>> field empty. >>>>>> >>>>>> Same principle applies for the second use case. >>>>>> >>>>>> What privacy problem do you see here? >>>>>> >>>>>> Best regards. >>>>>> /Francis >>>>>> >>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>> >>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>> directory, but I failed. >>>>>>> >>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>> second try: >>>>>>> >>>>>>> >>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-us= e-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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/ >>>>>> -- >>>>>> 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/ >>>> -- >>>> 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/ >> > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --00000000000087d7e105aca1db0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tom,

On Tue, Aug 11, 2020 at 6:42 PM= Tom Jones <thomasclinga= njones@gmail.com> wrote:
I guess I need to ask the group as a whole= then.
Will GNAP support self-issued Identifiers?
If so then = the AS is on the user's device.
I need to understand that SII= are in-scope.
Peace ..tom
I hope GN= AP will be designed to support SII. If you could drop some use cases here:= =C2=A0https://gith= ub.com/ietf-wg-gnap/general/wiki=C2=A0


On Tue, Aug 11, 2020= at 3:40 PM Francis Pouatcha <fpo@adorsys.de> wrote:
On Tue, Aug 11,= 2020 at 6:27 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
=
"The to= ken request must not mention any reference of the RS."
this = cannot be an absolute rule. I have cases were the client needs to tell the = user which they are coming back for additional grants.
The reason= is typically because a request by the client for data/access from the rs w= as rejected. The reason for the rejection is important for the client to ma= ke the case to the user for additional permissions.
Peace ..tom
- If you want privacy, don= 't expose RS identity to AS.
- If you want transparency, = expose RS identity to AS.
You can't have both....
/= Francis=C2=A0



On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha <fpo= =3D40adors= ys.de@dmarc.ietf.org> wrote:
Hello Fabian,
On Tue, = Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis,

I think Denis points = to the fact that, in the current situation, the AS receives the resource re= quest from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the= RS.
=C2=A0
Then it also implements the consent i= nterface (and possibly the login too) and so it also knows who validates an= d what is accepted or not.
Decoupling this doe= s not change the privacy context, as the AS issues the Token. AS needs to a= dd a reference to the=C2=A0RC in the token. SO AS can correlate on StudentI= d anyway.


I don&= #39;t think the abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thr= ead, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) wi= ll have to issue a VC (Verifiable Credential) to the Student (in his role o= f RC). The Student will then present this claim to UNIV-1 during his regist= ration. In this case we need no Grant negotiation and=C2=A0no AS.

Best regards.
/Francis
=C2=A0

Then I agree with y= ou on the audience field of the token, if left empty it simplifies part of = the problem, although it removes a big part of the control you may want fro= m directed tokens. That's why I'm willing to better develop the RS = hiding idea.=C2=A0

Fabie= n=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <f= po=3D40ado= rsys.de@dmarc.ietf.org> a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,
<= br>
what you describe in the use case seems to be the default beh= avior of the protocol. Let me map it with this abstract protocol flow:

+-----------+=C2=A0 =C2= =A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+-------= --------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2= =A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Con= troller |
| is UNIV-1 |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |= =C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Sta= ff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 = =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+= =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |= (1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |----------------------&= gt;|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,Stude= ntId,
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0OrchestratorId):AuthRequest[RecordType,StudentId]
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) = AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------------------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0OrchestratorId):Consent
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |= =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=A0AuthZ[RecordType,StudentId,OrchestratorId]
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,Stud= entId,OrchestratorId)
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +

we assume the authz request sent by "Client&= quot; to "AS" describes the protected resource without referring= =C2=A0to the authz server. An AS can issue the authz to release the graduat= ion record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,StudentId,Orchestr= atorId]), without any reference to the target university.=C2=A0

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource s= erver.
- RecordType: a reference = to a resource of type graduation record as understandable=C2=A0 by the reso= urce server.
-=C2=A0OrchestratorI= d: reference to the Orchestrator. Can be used to bind authz to Orchestrator= ..

But:
- RS must t= rust AS issued token.
-=C2=A0Stud= entId must be known to RS, AS and=C2=A0Orchestrator.

Therefor= e, the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.
=
Wha= t privacy problem do you see here?

Best regards.
=
/Francis

On Tue, Aug 4, 2020 at 5= :08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
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
https://= adorsys-platform.de/solutions/
--00000000000087d7e105aca1db0b-- From nobody Tue Aug 11 16:29:53 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 B700C3A0DCB for ; Tue, 11 Aug 2020 16:29:50 -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 xjxBEfkkccWX for ; Tue, 11 Aug 2020 16:29:47 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 ADD8D3A0C90 for ; Tue, 11 Aug 2020 16:29:46 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id 185so183293ljj.7 for ; Tue, 11 Aug 2020 16:29:46 -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=WWzyNpL/Wc/9t/l9nXctzHIVeIzc0JpACmoqFcIZDcY=; b=UMlcJ3iMvt9usI+wSFP9r92Ch0+Qnlsrsg8zRSoDufeoObuWt4BVOM5EdqdcMxDqAz MkSwNPvcJv3QT2xkjhWKSShEjB4ozuRHANKi8yj0CdgGv5Ie7nYMK8DF0PhPNpdgM3p6 DoGndyn2Rimdily9ZFsKUAPD+XAl7kh8PU+RkxDYeLz5PdHuvaELVzm77Ag5kEGVfMv3 o9wgKwQ0bx6V/wRw53O1DCwLYhh7tEv7YRAqqH57JKqhVCRmjrDeTJZ/69FGrkQvAM8g F1D4v4dMLwa4NDJc3ZW4yD4Yw3G/xs+9MJJPMMjOGt7s/O96W3vVjMKqNRt2KcsfLoAI 16Cg== 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=WWzyNpL/Wc/9t/l9nXctzHIVeIzc0JpACmoqFcIZDcY=; b=pCd8Q2qbqKuxMA0JZYlLp2GQAC38VBsfVUKnaHSVOj5NRdbxGsQUHLPbTYyUH0lTQB oFMOwi+6mATQaeyGQkGpNhPaHTh06pMP8EA1zLFQ7gbTqLCVUEGVh3ePeVM05TgBDgCc ytgiDhh31fsmFvij4e5ib5GaPMg6t1Ct2LwLGKqU2ay9NOCVRHqXfnihSQRJllafdVAU AcZN3e7FvoMalpYww6CR+7tFy8A0cRTBTpNmCMfbI3w4GYgWP+lWI61JiLNIwjwgRLhB 0ibarhQzhSzcEr+huOA7NKIUQkBc6WSe5gOEc0TDbruoKfWZuXfuL84YrWvPoaQRtyOT SRQA== X-Gm-Message-State: AOAM5324sRTLSjoQwhDgfxZ6Ix4NBwo6l7edrO4D869M+266aTXoW+D5 6WTq8Gx8yqtl9XbOnhMVmhmWpR3Rqdqp0fVSohU= X-Google-Smtp-Source: ABdhPJwgcb22ZpocTGpk6xfnxRjKybdT6P9IQch/KORbmEpx2KhRFistnsNtU3OoAmdraNeUc1e4lkQFm5xYD2FVSfw= X-Received: by 2002:a2e:865a:: with SMTP id i26mr3774188ljj.246.1597188584809; Tue, 11 Aug 2020 16:29:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 16:29:08 -0700 Message-ID: To: Tom Jones Cc: Francis Pouatcha , Fabien Imbault , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003ca79705aca2726d" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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, 11 Aug 2020 23:29:51 -0000 --0000000000003ca79705aca2726d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tom, do you have a straw man on how a client would interact with an AS on the user's device? =E1=90=A7 On Tue, Aug 11, 2020 at 3:43 PM Tom Jones wrote: > I guess I need to ask the group as a whole then. > Will GNAP support self-issued Identifiers? > If so then the AS is on the user's device. > I need to understand that SII are in-scope. > Peace ..tom > > > On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha wrote: > >> On Tue, Aug 11, 2020 at 6:27 PM Tom Jones >> wrote: >> >>> "The token request must not mention any reference of the RS." >>> this cannot be an absolute rule. I have cases were the client needs to >>> tell the user which they are coming back for additional grants. >>> The reason is typically because a request by the client for data/access >>> from the rs was rejected. The reason for the rejection is important for= the >>> client to make the case to the user for additional permissions. >>> Peace ..tom >>> >> - If you want privacy, *don't* expose RS identity to AS. >> - If you want transparency, expose RS identity to AS. >> You can't have both..... >> /Francis >> >>> >>> >>> >>> On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> wrote: >>> >>>> Hello Fabian, >>>> >>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Francis, >>>>> >>>>> I think Denis points to the fact that, in the current situation, the >>>>> AS receives the resource request from the Client and therefore knows = what >>>>> tokens are asked. >>>>> >>>> The token request must not mention any reference of the RS. >>>> >>>> >>>>> Then it also implements the consent interface (and possibly the login >>>>> too) and so it also knows who validates and what is accepted or not. >>>>> >>>> Decoupling this does not change the privacy context, as the AS issues >>>> the Token. AS needs to add a reference to the RC in the token. SO AS c= an >>>> correlate on StudentId anyway. >>>> >>>> >>>>> I don't think the abstract flow deals with those privacy concerns. >>>>> >>>> To solve the privacy problem addressed in this thread, we need to go >>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to iss= ue a >>>> VC (Verifiable Credential) to the Student (in his role of RC). The Stu= dent >>>> will then present this claim to UNIV-1 during his registration. In thi= s >>>> case we need no Grant negotiation and no AS. >>>> >>>> Best regards. >>>> /Francis >>>> >>>>> >>>> >>>>> >>>>> Then I agree with you on the audience field of the token, if left >>>>> empty it simplifies part of the problem, although it removes a big pa= rt of >>>>> the control you may want from directed tokens. That's why I'm willing= to >>>>> better develop the RS hiding idea. >>>>> >>>>> Fabien >>>>> >>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>> >>>>>> Hello Denis, >>>>>> >>>>>> what you describe in the use case seems to be the default behavior o= f >>>>>> the protocol. Let me map it with this abstract protocol flow: >>>>>> >>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>> +---------------------+ >>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>> Resource Controller | >>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>> is | >>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>> Student | >>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>> +---------------------+ >>>>>> |(1) RegisterStudent | | | >>>>>> | >>>>>> |---------------------->| | | >>>>>> | >>>>>> | |(2) >>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>> | | >>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>> | |<-------------->| | >>>>>> | >>>>>> | | | | >>>>>> | >>>>>> | |(3) >>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>> | |--------------------------->| >>>>>> | >>>>>> | | | |(4) >>>>>> ConsentRequest(RecordType, >>>>>> | | | | >>>>>> OrchestratorId):Consent >>>>>> | | | >>>>>> |<-------------->| >>>>>> | >>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>> | |<---------------------------| >>>>>> | >>>>>> | | | | >>>>>> | >>>>>> | |(2) >>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>> | | :RecordOf[StudentId] | >>>>>> | >>>>>> | |<-------------->| | >>>>>> | >>>>>> |(7) Registered | | | >>>>>> | >>>>>> |<----------------------| | | >>>>>> | >>>>>> + + + + >>>>>> + >>>>>> >>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>> protected resource without referring to the authz server. An AS can = issue >>>>>> the authz to release the graduation record of a student >>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refere= nce to >>>>>> the target university. >>>>>> >>>>>> What matters for this authz object is: >>>>>> - StudentId: a reference to the student as known to the resource >>>>>> server. >>>>>> - RecordType: a reference to a resource of type graduation record as >>>>>> understandable by the resource server. >>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>>>> authz to Orchestrator.. >>>>>> >>>>>> But: >>>>>> - RS must trust AS issued token. >>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>> >>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>> field empty. >>>>>> >>>>>> Same principle applies for the second use case. >>>>>> >>>>>> What privacy problem do you see here? >>>>>> >>>>>> Best regards. >>>>>> /Francis >>>>>> >>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>> >>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>> directory, but I failed. >>>>>>> >>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>> second try: >>>>>>> >>>>>>> >>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-us= e-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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/ >>>>>> -- >>>>>> 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/ >>>> -- >>>> 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/ >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000003ca79705aca2726d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tom, do you have a straw man on how a client would interac= t with an AS on the user's device?
3D""=E1=90=A7
=
On Tue= , Aug 11, 2020 at 3:43 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I guess I need to= ask the group as a whole then.
Will GNAP support self-issued Identifie= rs?
If so then the AS is on the user's device.
I ne= ed to understand that SII are in-scope.
Peace ..tom


On T= ue, Aug 11, 2020 at 3:40 PM Francis Pouatcha <fpo@adorsys.de> wrote:
O= n Tue, Aug 11, 2020 at 6:27 PM Tom Jones <thomasclinganjones@gmail.com> wr= ote:
"The token request must not mention any reference of the RS."
this cannot be an absolute rule. I have cases were the client need= s to tell the user which they are coming back for additional grants.
<= div>The reason is typically because a request by the client for data/access= from the rs was rejected. The reason for the rejection is important for th= e client to make the case to the user for additional permissions.
Peace ..tom
- If you want p= rivacy, don't expose RS identity to AS.
- If you want = transparency, expose RS identity to AS.
You can't have both..= ...
/Francis=C2=A0



On Tue, Aug 11, 2020 at 2:27 PM Francis= Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:


=C2=A0

= Then I agree with you on the audience field of the token, if left empty it = simplifies part of the problem, although it removes a big part of the contr= ol you may want from directed tokens. That's why I'm willing to bet= ter develop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Fra= ncis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> a =C3=A9crit=C2=A0:
Hell= o=C2=A0Denis,

what you describe in the use case seems to= be the default behavior of the protocol. Let me map it with this abstract = protocol flow:

+----= -------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+--= --+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Or= chestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2= =A0| Resource Controller |
| is U= NIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is= UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2= =A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2= =A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+--------------= -------+
=C2=A0 |(1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |--= -------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIn= tent(RecordType,StudentId,
=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest[RecordType,Stude= ntId]
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----= ---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-------------------= -------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----------= ---->|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,Orchest= ratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(R= ecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 += =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +

we assume the authz request sent by= "Client" to "AS" describes the protected resource with= out referring=C2=A0to the authz server. An AS can issue the authz to releas= e the graduation record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,Stude= ntId,OrchestratorId]), without any reference to the target university.=C2= =A0

What matters for this authz object is:
<= font face=3D"monospace">- StudentId: a reference to the student as known to= the resource server.
- RecordTyp= e: a reference to a resource of type graduation record as understandable=C2= =A0 by the resource server.
-=C2= =A0OrchestratorId: reference to the Orchestrator. Can be used to bind authz= to Orchestrator..

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2=A0Orchestrator.=

Therefore, the AS does not need to know the RS. Keep the audience f= ield empty.

Same principle applies for the second use case.

What privacy problem do you see here?

Best reg= ards.
/Francis
=
On Tue= , Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


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


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000003ca79705aca2726d-- From nobody Tue Aug 11 16:38:15 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 48A153A0D5D for ; Tue, 11 Aug 2020 16:38:14 -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 6C_tvfddmcxd for ; Tue, 11 Aug 2020 16:38:12 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 60E523A0DF6 for ; Tue, 11 Aug 2020 16:38:12 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id s9so189254lfs.4 for ; Tue, 11 Aug 2020 16:38:12 -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=8TTN9YNBJ0oqd+rcayvS0m1YtI4Ye4rJVX/Y3cyNIcg=; b=apfgtfn+By+1kZrRlNwtM8hyGoTsBp2Vl2Q1zLcCKQM53SwiS5KBvbK32tAzHCY+IX t3645FPnU5EnoAGHuYM2f51/dj8NGqHrA6tsT3a+2FgjWy1GVIz5Fe5jn49rJ7hZYwxa vZluKRvz10OoOAubrGl+ZMhah6koGlKV2JctTaVD6t0AyOtEzCySSP5uNHz4Q3MP99xQ pX7Bj4NKnzoWtqfSmEzWUl6rztQXCvfNPIbjmypCro84NVIYTPUQCQLuTiua98gpPFbW GhuRVZzXwQTOVCz1SSP2PDwqaQ3w0dL5+mQn8slx3hTbTzMcuj0bWJbzA4XjUpwyOHIK 4W4Q== 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=8TTN9YNBJ0oqd+rcayvS0m1YtI4Ye4rJVX/Y3cyNIcg=; b=f53TeyjzZ5wf7ufWipSSbDfpvmTWUfC2hhAb4DtYnVws940vTZvdKg0hTmO7vsP4MG X+MPXp/K2meLLD8Pp3ZLmtqpLvuhMVCXqfhoAze8e3kl+FRWrmZG9rtFrYBeQmErXM4y rT7yG3vIq4KRJde3pSC0pHx703gQdu8PHKkdru4y1Ls9+YZyV6OYZwvqWmDO9NfrObgG 7I2DYVjBaIKnUjcdssDVpuUH/zGAJkh0wLoZW9bFmjYddB2htF+M8e+YTIuQdfcYy7go Y6uqMUL3i5cN2ETET10/UHK3hD2qLpQ9oQlMvOTwMIkkVGVq2ltrkllsUnNkmT7aEiuU cuxA== X-Gm-Message-State: AOAM532ZeLz6Ye1t/ekVJe9fUMIbHzPcsd6hZjGJjz7Vdq8IqrnYShUT cHkbBxJajIDDkU81HLxvyaJkVdcp+NVBosY/Kts= X-Google-Smtp-Source: ABdhPJz2CtxHi70n0LAFrX9cflNTZmPzUOwjcfHlaAmIH/LDEgwT1dWO1LKcVMSi5oPq7N7ExJe/RA5sEOgthV9bJZ4= X-Received: by 2002:a19:70c:: with SMTP id 12mr4278146lfh.207.1597189090381; Tue, 11 Aug 2020 16:38:10 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 16:37:34 -0700 Message-ID: To: Francis Pouatcha Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005f11eb05aca290ad" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 11 Aug 2020 23:38:14 -0000 --0000000000005f11eb05aca290ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, responses inline ... On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha wrote: > Hello Dick, > > On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt wrote: > >> Hi Francis >> >> The user is an entity, not a role in the protocol in how I am defining >> roles, so steps (1) and (7) are confusing to me on what is happening. >> > "Requestor" is the role (*was* User). So the UML participant refers to > the role "Requestor" > I still don't understand what is happening in (1) and (7) > > >> I also think that (2) could be an extension to GNAP, rather than part of >> the core protocol. >> > If you make it an extension, you hide. It shall rather be an optional, > integral part of the protocol. > Most deployments today accomplish (2) by the developer reading RS documentation. I'm in favor of showing that step in an abstract diagram. But it is not clear to me what the requirements for (2), and they may vary radically across use cases, so putting it in the core document seems to be getting ahead of ourselves. > In some open banking designs, > - the "Orchestrator/Negotiator/Client" will not know the AS to talk to > unless the call (2). > Have you put these use cases in the wiki? > - the request (2) might result in an exemption, meaning no need for > further authorization, allowing to skip (3, 4, 5) and even (6). > Agreed. > =E1=90=A7 --0000000000005f11eb05aca290ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis, responses inline ...=C2=A0

On Tue, Aug 11,= 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,<= div>

On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:=
Hi Francis

The user is an entity, not a role in the pr= otocol in how I am defining roles, so steps (1) and (7) are confusing to me= on what is happening.
"Requestor" i= s the role (was User). So the UML participant refers=C2=A0to the rol= e "Requestor"

I= still don't understand what is happening in (1) and (7)
=C2= =A0


I also think tha= t (2) could be an extension to GNAP, rather than part of the core protocol.=
If you make it an extension, you hide. It sha= ll rather be an optional, integral part of the protocol.
=

Most deployments today accomplish (2) by t= he developer reading RS documentation.

I'm in = favor of showing that step in an abstract diagram. But it is not clear to m= e what the requirements for (2), and they may vary radically across use cas= es, so putting it in the core document seems to be getting ahead of ourselv= es.
=C2=A0
In some open banking desi= gns,=C2=A0
- the "Orchestrator/Negotiator/Client" will = not know the AS to talk to unless the call (2).

Have you put these use cases in the wiki?
= =C2=A0
- the request (2) might result in an ex= emption, meaning no need for further authorization, allowing to skip (3, 4,= 5) and even (6).

Agreed.=
3D""= =E1=90=A7
--0000000000005f11eb05aca290ad-- From nobody Tue Aug 11 16:38:24 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 0716C3A0DEC for ; Tue, 11 Aug 2020 16:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5HMMJDQnzq1N for ; Tue, 11 Aug 2020 16:38:18 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B713A0E11 for ; Tue, 11 Aug 2020 16:38:18 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 07BNbDFS016074; Tue, 11 Aug 2020 19:37:56 -0400 Received: from w92expo8.exchange.mit.edu (18.7.74.62) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 11 Aug 2020 19:37:18 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo8.exchange.mit.edu (18.7.74.62) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 11 Aug 2020 19:38:08 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 11 Aug 2020 19:38:08 -0400 From: Justin Richer To: Dick Hardt , Francis Pouatcha CC: Denis , Benjamin James Kaduk , "txauth@ietf.org" Thread-Topic: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) Thread-Index: AQHWaWi+SiWejZSeFUGxBevdwVA58akmvl2AgAE19QCAAJztgIAACv4AgAEIxYCAAOZ0AIAH/PWAgAFDWQD//9H6AQ== Date: Tue, 11 Aug 2020 23:38:08 +0000 Message-ID: <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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, 11 Aug 2020 23:38:23 -0000 SWYgZGVmaW5lZCBhcyB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZSBjbGllbnQgc29mdHdhcmUsIHRo ZW4gdGhlIHVzZXIgaXMgYSByb2xlLiBJIGJlbGlldmUgdGhpcyBpcyBtb3JlIGFjY3VyYXRlIGFu ZCBpbmNsdXNpdmUgdGhhbiB0aGUgZGVmaW5pdGlvbiB5b3UgaGF2ZSBwcm9wb3NlZCB3aXRoIHRo ZSB1c2VyIGFzIGFuIGVudGl0eS4gDQoNCiAtIEp1c3Rpbg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogRGljayBIYXJkdCBbZGljay5oYXJkdEBnbWFpbC5j b21dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTEsIDIwMjAgNjoyMSBQTQ0KVG86IEZyYW5jaXMg UG91YXRjaGENCkNjOiBKdXN0aW4gUmljaGVyOyBEZW5pczsgQmVuamFtaW4gSmFtZXMgS2FkdWs7 IHR4YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtHTkFQXSBbVHhhdXRoXSBSZXZpc2l0aW5n IHRoZSBwaG90byBzaGFyaW5nIGV4YW1wbGUgKGEgZHJpdmluZyB1c2UgY2FzZSBmb3IgdGhlIGNy ZWF0aW9uIG9mIE9BdXRoKQ0KDQpIaSBGcmFuY2lzDQoNClRoZSB1c2VyIGlzIGFuIGVudGl0eSwg bm90IGEgcm9sZSBpbiB0aGUgcHJvdG9jb2wgaW4gaG93IEkgYW0gZGVmaW5pbmcgcm9sZXMsIHNv IHN0ZXBzICgxKSBhbmQgKDcpIGFyZSBjb25mdXNpbmcgdG8gbWUgb24gd2hhdCBpcyBoYXBwZW5p bmcuDQoNCkkgYWxzbyB0aGluayB0aGF0ICgyKSBjb3VsZCBiZSBhbiBleHRlbnNpb24gdG8gR05B UCwgcmF0aGVyIHRoYW4gcGFydCBvZiB0aGUgY29yZSBwcm90b2NvbC4NCg0KDQoNCg0KDQpPbiBN b24sIEF1ZyAxMCwgMjAyMCBhdCA4OjA0IFBNIEZyYW5jaXMgUG91YXRjaGEgPGZwb0BhZG9yc3lz LmRlPG1haWx0bzpmcG9AYWRvcnN5cy5kZT4+IHdyb3RlOg0KSW4gdGhpcyBjb250ZXh0LCBJIHN1 Z2dlc3Qgd2UgcGljayBzb21lIHdvcmRzIHRvIHdvcmsgd2l0aCwgYW5kIHNoYXJwZW4gdGhlbSBh cyB3ZSBtb3ZlIG9uLCBkaXNjb3ZlciBhbmQgbWFwIG5ldyB1c2UgY2FzZXMgdG8gdGhlIHByb3Rv Y29sLg0KDQpJbiB0aGlzIGRpYWdyYW0gZnJvbSB0aGUgb3JpZ2luYWwgdGhyZWFkIChodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC9JYVNMQ183Ml9LaW1qT0JKcWRt UVktSk9HTncvKSwgSSByZXBsYWNlZCB0aGUgd29yZHM6DQoNCistLS0tLS0tLS0tLSsgICAgICAr LS0tLS0tLS0tLS0tLS0rICArLS0tLSsgICstLS0tKyAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CnwgUmVxdWVzdG9yIHwgICAgICB8IE9yY2hlc3RyYXRvciB8ICB8ICAgIHwgIHwgR1MgfCAgfCBS ZXNvdXJjZSBDb250cm9sbGVyIHwNCnwgICB3YXMgICAgIHwgICAgICB8ICAgICB3YXMgICAgICB8 ICB8IFJTIHwgIHwgb3IgfCAgfCAgICAgICAgIHdhcyAgICAgICAgIHwNCnwgIFVzZXIgICAgIHwg ICAgICB8ICAgQ2xpZW50ICAgICB8ICB8ICAgIHwgIHwgQVMgfCAgfCAgICBSZXNvdXJjZSBPd25l ciAgIHwNCistLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0rICArLS0tLSsgICstLS0t KyAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgfCgxKSBTZXJ2aWNlUmVxdWVzdCAgICAgfCAg ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICB8DQogIHwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tPnwgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICB8ICAgICAg ICAgICAgICAgICAgICAgICB8KDIpIFNlcnZpY2VJbnRlbnQ6QXV0aFpDaGFsbGVuZ2UgICAgIHwN CiAgfCAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tPnwgICAgICAgfCAgICAgICAg ICAgICAgICB8DQogIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAg IHwgICAgICAgICAgICAgICAgfA0KICB8ICAgICAgICAgICAgICAgICAgICAgICB8KDMpIEF1dGha UmVxdWVzdChBdXRoWkNoYWxsZW5nZSkgICAgIHwNCiAgfCAgICAgICAgICAgICAgICAgICAgICAg fC0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICB8DQogIHwgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAgIHwoNCkgQ29uc2VudFJlcXVlc3Q6R3JhbnQN CiAgfCAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgfDwtLS0tLS0t LS0tLS0tLT58DQogIHwgICAgICAgICAgICAgICAgICAgICAgIHwoNSkgR3JhbnRBY2Nlc3MoQXV0 aFopICAgICAgICAgICAgICAgfA0KICB8ICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0t LS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgIHwNCiAgfCAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICB8DQogIHwgICAgICAgICAgICAg ICAgICAgICAgIHwoNikgU2VydmljZVJlcXVlc3QoQXV0aFopOlNlcnZpY2VSZXNwb25zZQ0KICB8 ICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0+fCAgICAgICB8ICAgICAgICAgICAg ICAgIHwNCiAgfCg3KSBTZXJ2aWNlUmVzcG9uc2UgICAgfCAgICAgICAgICAgIHwgICAgICAgfCAg ICAgICAgICAgICAgICB8DQogIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgICB8 ICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICArICAgICAgICAgICAgICAgICAgICAgICArICAg ICAgICAgICAgKyAgICAgICArICAgICAgICAgICAgICAgICsNCg0KVGhlIHB1cnBvc2Ugb2YgdGhl IEdOQVAgcHJvdG9jb2wgaXMgdG8gaGVscCBuZWdvdGlhdGUgYWNjZXNzIHRvIGEgcHJvdGVjdGVk IHJlc291cmNlLiBJdCBzdGFydHMgd2l0aCBhIHJlcXVlc3RvciBkZWxlZ2F0aW5nIGFjdGl2aXR5 IHRvIGFuIG9yY2hlc3RyYXRvci4gVGhlc2UgYXJlIGFsbCByb2xlcywgbm8gZW50aXRpZXMuIExl dCBmb2N1cyBvbiBtYXBwaW5nIHRoZSB1c2UgY2FzZXMgdG8gdGhlIHByb3RvY29sIHJvbGVzIGFu ZCBpbnRlcmFjdGlvbnMgc28gd3dlIGNhbiBkaXNjb3ZlciB3aGF0IGlzIG1pc3NpbmcuDQoNCkl0 IHNlZW1zIGN1bWJlcnNvbWUgdG8gdXNlIGl0IGluIGRpc2N1c3Npb25zIGFzIGl0IGlzIGltcG9z c2libGUgdG8gZ2l2ZSB0aGUgd29yZCAiQ2xpZW50IiBhIGNsZWFyIGRlZmluaXRpb24uDQoNCldl IGNhbiBtZW50aW9uIGluIHRoZSBmaW5hbCBkb2N1bWVudCwgdGhhdCB0aGUgIk9yY2hlc3RyYXRv ciIgKG9yIHdoYXRldmVyIHdvcmQgd2UgZmluYWxseSB1c2UpIHBsYXlzIHRoZSBzYW1lIHJvbGUg YXMgdGhlICJDbGllbnQiIGluIG9BdXRoMi4NCg0KQmVzdCByZWdhcmRzLg0KL0ZyYW5jaXMNCg0K DQoNCg0KDQpPbiBXZWQsIEF1ZyA1LCAyMDIwIGF0IDk6MDUgUE0gRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQpJIGFn cmVlIHdpdGggSnVzdGluLiBSZWRlZmluaW5nIHdlbGwgdXNlZCB0ZXJtcyB3aWxsIGxlYWQgdG8g c2lnbmlmaWNhbnQgY29uZnVzaW9uLiBJZiB3ZSBoYXZlIGEgZGlmZmVyZW50IHJvbGUgdGhhbiB3 aGF0IHdlIGhhdmUgaGFkIGluIHRoZSBwYXN0LCB0aGVuIHRoYXQgcm9sZSBzaG91bGQgaGF2ZSBh IG5hbWUgbm90IGJlaW5nIHVzZWQgYWxyZWFkeSBpbiBPQXV0aCBvciBPSURDLg0KDQpHaXZlbiB3 aGF0IHdlIGhhdmUgbGVhcm5lZCwgYW5kIG15IG93biBleHBlcmllbmNlIGV4cGxhaW5pbmcgd2hh dCBhIENsaWVudCBpcywgYW5kIGlzIG5vdCwgaW1wcm92aW5nIHRoZSBkZWZpbml0aW9uIGZvciBD bGllbnQgY291bGQgcHJvdmUgdXNlZnVsLiBJIGFtIG5vdCBzdWdnZXN0aW5nIHRoZSB0ZXJtIGJl IHJlZGVmaW5lZCwgYnV0IGNsYXJpZmllZC4NCg0KRm9yIGV4YW1wbGUsIGNsYXJpZnlpbmcgdGhh dCBhIENsaWVudCBpcyBhIHJvbGUgYW4gZW50aXR5IHBsYXlzIGluIHRoZSBwcm90b2NvbCwgYW5k IHRoYXQgdGhlIHNhbWUgZW50aXR5IG1heSBwbGF5IG90aGVyIHJvbGVzIGF0IG90aGVyIHRpbWVz LCBvciBzb21lIG90aGVyIGxhbmd1YWdlIHRvIGhlbHAgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuICJy b2xlIiBhbmQgImVudGl0eSIuDQoNCi9EaWNrDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3Qu Y29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29u dGVudCZndWlkPWU0OGUxM2Y0LTIzMDYtNGQ3Yy04NjU0LWQ1MGUwMGRiYWMzYV3hkKcNCg0KT24g V2VkLCBBdWcgNSwgMjAyMCBhdCA4OjIwIEFNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0Li5l ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KSeKAmW0gaW4gZmF2b3Igb2YgY29t aW5nIHVwIHdpdGggYSBuZXcgdGVybSB0aGF04oCZcyBhIGJldHRlciBmaXQsIGJ1dCBJ4oCZbSBu b3QgcmVhbGx5IGluIGZhdm9yIG9mIHRha2luZyBhbiBleGlzdGluZyB0ZXJtIGFuZCBhcHBseWlu ZyBhIGNvbXBsZXRlbHkgbmV3IGRlZmluaXRpb24gdG8gaXQuIEluIG90aGVyIHdvcmRzLCBJIHdv dWxkIHNvb25lciBzdG9wIHVzaW5nIOKAnGNsaWVudOKAnSBhbmQgY29tZSB1cCB3aXRoIGEgbmV3 LCBtb3JlIHNwZWNpZmljIGFuZCBhY2N1cmF0ZSB0ZXJtIGZvciB0aGUgcm9sZSB0aGFuIHRvIGRl ZmluZSDigJxjbGllbnTigJ0gYXMgbWVhbmluZyBzb21ldGhpbmcgY29tcGxldGVseSBkaWZmZXJl bnQuIFdlIGRpZCB0aGlzIGluIGdvaW5nIGZyb20gT0F1dGggMSB0byBPQXV0aCAyIGFscmVhZHks IG1vdmluZyBmcm9tIHRoZSBldmVuLW1vcmUtY29uZnVzaW5nIOKAnGNvbnN1bWVy4oCdIHRvIOKA nGNsaWVudOKAnSwgYnV0IE9BdXRoIDIgZG9lc27igJl0IHVzZSB0aGUgdGVybSDigJxjb25zdW1l cuKAnSBhdCBhbGwsIG5vciBkb2VzIGl0IHVzZSDigJxzZXJ2ZXLigJ0gb24gaXRzIG93biBidXQg aW5zdGVhZCBhbHdheXMgcXVhbGlmaWVzIGl0IHdpdGgg4oCcQXV0aG9yaXphdGlvbiBTZXJ2ZXLi gJ0gYW5kIOKAnFJlc291cmNlIFNlcnZlcuKAnS4NCg0KR05BUCBjYW4gZG8gc29tZXRoaW5nIHNp bWlsYXIsIGluIG15IG9waW5pb24uIEJ1dCB3aGF0IHdlIGNhbuKAmXQgZG8gaXMgaWdub3JlIHRo ZSBmYWN0IHRoYXQgR05BUCBpcyBnb2luZyB0byBiZSBjb21pbmcgdXAgaW4gYSB3b3JsZCB0aGF0 IGlzIGFscmVhZHkgcGVybWVhdGVkICBieSBPQXV0aCAyIGFuZCBpdHMgdGVybWlub2xvZ3kuIFdl IGRvbuKAmXQgaGF2ZSBhIGJsYW5rIHNsYXRlIHRvIHdvcmsgd2l0aCwgYnV0IG5laXRoZXIgYXJl IHdlIGJvdW5kIHRvIHVzZSB0aGUgc2FtZSB0ZXJtcyBhbmQgY29uc3RydWN0cyBhcyBiZWZvcmUu IEl04oCZcyBnb2luZyB0byBiZSBhIGRlbGljYXRlIGJhbGFuY2UhDQoNCiDigJQgSnVzdGluDQoN Ck9uIEF1ZyA0LCAyMDIwLCBhdCAzOjMyIFBNLCBXYXJyZW4gUGFyYWQgPHdwYXJhZEByaG9zeXMu Y2g8bWFpbHRvOndwYXJhZEByaG9zeXMuY2g+PiB3cm90ZToNCg0KSSB0aGluayB0aGF0IGlzIGZ1 bmRhbWVudGFsbHkgcGFydCBvZiB0aGUgcXVlc3Rpb246DQpXZSBhcmUgY2xlYXIgdGhhdCB3ZSBh cmUgcHJvZHVjaW5nIGEgcHJvdG9jb2wgdGhhdCBpcw0KY29uY2VwdHVhbGx5IChpZiBub3QgbW9y ZSBzdHJvbmdseSkgcmVsYXRlZCB0byBPQXV0aCAyLjAsIGFuZCByZXVzaW5nIHRlcm1zDQpmcm9t IE9BdXRoIDIuMCBidXQgd2l0aCBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgbWF5IGxlYWQgdG8gdW5u ZWNlc3NhcnkNCmNvbmZ1c2lvbg0KDQpJZiB3ZSBzYXkgdGhhdCB0aGlzIGRvY3VtZW50IGFzc3Vt ZXMgT0F1dGgyLjAgdGVybWlub2xvZ3ksIHRoZW4gd2Ugc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIG1l YW5pbmdzIG9mIGFueSBkZWZpbml0aW9uLiBJZiB3ZSBhcmUgc2F5aW5nIHRoaXMgc3VwZXJzZWRl cyBvciByZXBsYWNlcyB3aGF0IE9BdXRoIDIuMCBjcmVhdGVzLCB0aGVuIHdlIHNob3VsZCBwaWNr IHRoZSBiZXN0IHdvcmQgZm9yIHRoZSBqb2IgYW5kIGlnbm9yZSBjb25mbGljdGluZyBtZWFuaW5n cyBmcm9tIE9BdXRoIDIuMC4gSSBoYXZlIGEgbG90IG9mIGZpcnN0IGhhbmQgZXhwZXJpZW5jZSBv ZiBpbmR1c3RyaWVzICJydWluaW5nIHdvcmRzIiwgYW5kIGF0dGVtcHRpbmcgdG8gc2lkZS1zdGVw IHRoZSBwcm9ibGVtIHJhdGhlciB0aGFuIHJlZGVmaW5pbmcgdGhlIHdvcmQganVzdCBjb25mdXNl cyBldmVyeW9uZSBhcyBldmVyeW9uZSBmb3JnZXRzIHRoZSBvcmlnaW5hbCBtZWFuaW5nIGFzIG5l dyBkb2N1bWVudHMgY29tZSBvdXQsIGJ1dCB0aGUgY29uZnVzaW9uIHdpdGggdGhlIHVzZSBvZiBh IG5vbi1vYnZpb3VzIHdvcmQgY29udGludWVzLg0KDQpGb29kIGZvciB0aG91Z2h0Lg0KLSBXYXJy ZW4NCg0KW2h0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50LmNvbS9ETmlEeDFRR0lyU3FNUEtE TjFvS2V2eFl1eVZSWHNxaFhkZlpPc1c1NlJmMkE3NG1VS2JBUHRySlNOdzRxeW5rU2pvbHRXa1BZ ZEJoYVpKZzFCTzQ1WU9jMXhzNnI5S0oxZllzTkhvZ1ktbmg2aGp1SW05R0NlQlJSenJTYzhrV2NV U050dUFdDQoNCldhcnJlbiBQYXJhZA0KRm91bmRlciwgQ1RPDQoNClNlY3VyZSB5b3VyIHVzZXIg ZGF0YSBhbmQgY29tcGxldGUgeW91ciBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVt ZW50IEF1dGhyZXNzPGh0dHBzOi8vYml0Li5seS8zN1NTTzFwPi4NCg0KDQpPbiBUdWUsIEF1ZyA0 LCAyMDIwIGF0IDg6NTMgUE0gQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU8bWFpbHRvOmth ZHVrQG1pdC5lZHU+PiB3cm90ZToNCkhpIERlbmlzLA0KDQpPbiBUdWUsIEF1ZyAwNCwgMjAyMCBh dCAxMTozMTozNEFNICswMjAwLCBEZW5pcyB3cm90ZToNCj4gSGkgSnVzdGluLA0KPg0KPiBTaW5j ZSB5b3UgcmVwbGllZCBpbiBwYXJhbGxlbCwgSSB3aWxsIG1ha2UgYSByZXNwb25zZSBzaW1pbGFy IHRvIHRoZSBvbmUNCj4gSSBzZW50IHRvIERpY2suDQo+DQo+ID4gSGkgRGVuaXMsDQo+ID4NCj4g PiBJIHRoaW5rIHRoZXJl4oCZcyBzdGlsbCBhIHByb2JsZW0gd2l0aCB0aGUgdGVybWlub2xvZ3kg aW4gdXNlIGhlcmUuIFdoYXQNCj4gPiB5b3UgZGVzY3JpYmUgYXMgUlMyLCB3aGljaCBtaWdodCBp biBmYWN0IGJlIGFuIFJTIHVudG8gaXRzZWxmLCBpcyBhDQo+ID4g4oCcQ2xpZW504oCdIGluIE9B dXRoIHBhcmxhbmNlIGJlY2F1c2UgaXQgaXMgL2EgY2xpZW50IG9mIFJTMS8uIFdoYXQgeW91DQo+ ID4gY2FsbCBhIOKAnGNsaWVudOKAnSBoYXMgbm8gYW5hbG9ndWUgaW4gdGhlIE9BdXRoIHdvcmxk LCBidXQgaXQgaXMgbm90IGF0DQo+ID4gYWxsIHRoZSBzYW1lIGFzIGFuIE9BdXRoIGNsaWVudC4g SSBhcHByZWNpYXRlIHlvdXIgbWFwcGluZyBvZiB0aGUNCj4gPiBlbnRpdGllcyBiZWxvdywgYnV0 IGl0IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBob2xkIGEgZGlzY3Vzc2lvbiBpZiB3ZQ0KPiA+IGFy ZW7igJl0IHVzaW5nIHRoZSBzYW1lIHRlcm1zLg0KPiA+DQo+ID4gVGhlIGdvb2QgbmV3cyBpcyB0 aGF0IHRoaXMgaXNu4oCZdCBPQXV0aCwgYW5kIGFzIGEgbmV3IFdHIHdlIGNhbiBkZWZpbmUNCj4g PiBvdXIgb3duIHRlcm1zLiBUaGUgYmFkIG5ld3MgaXMgdGhhdCB0aGlzIGlzIHJlYWxseSBoYXJk IHRvIGRvLg0KPiA+DQo+ID4gSW4gR05BUCwgd2Ugc2hvdWxkbuKAmXQganVzdCByZS11c2UgZXhp c3RpbmcgdGVybXMgd2l0aCBuZXcgZGVmaW5pdGlvbnMsDQo+ID4gYnV0IHdl4oCZdmUgZ290IGEg Y2hhbmNlIHRvIGJlIG1vcmUgcHJlY2lzZSB3aXRoIGhvdyB3ZSBkZWZpbmUgdGhpbmdzLg0KPg0K PiBJbiB0aGUgSVNPIGNvbnRleHQsIGVhY2ggZG9jdW1lbnQgbXVzdCBkZWZpbmUgaXRzIG93biB0 ZXJtaW5vbG9neS4gVGhlDQo+IGJvaWxlciBwbGF0ZSBmb3IgUkZDcyBkb2VzIG5vdCBtYW5kYXRl IGEgdGVybWlub2xvZ3kgb3IgZGVmaW5pdGlvbnMgc2VjdGlvbg0KPiBidXQgZG9lcyBub3QgcHJl dmVudCBpdCBlaXRoZXIuIFRoZSB2b2NhYnVsYXJ5IGlzIGxpbWl0ZWQgYW5kIGFzIGxvbmcgYXMN Cj4gd2UgY2xlYXJseSBkZWZpbmUgd2hhdCBvdXIgdGVybXMgYXJlIG1lYW5pbmcsIHdlIGNhbiBy ZS11c2UgYSB0ZXJtIGFscmVhZHkNCj4gdXNlZCBpbiBhbm90aGVyIFJGQy4gVGhpcyBpcyBhbHNv IHRoZSBJU08gYXBwcm9hY2guDQoNCkp1c3QgYmVjYXVzZSB3ZSBjYW4gZG8gc29tZXRoaW5nIGRv ZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBpdCBpcyBhDQpnb29kIGlkZWEgdG8gZG8gc28u ICBXZSBhcmUgY2xlYXIgdGhhdCB3ZSBhcmUgcHJvZHVjaW5nIGEgcHJvdG9jb2wgdGhhdCBpcw0K Y29uY2VwdHVhbGx5IChpZiBub3QgbW9yZSBzdHJvbmdseSkgcmVsYXRlZCB0byBPQXV0aCAyLjAs IGFuZCByZXVzaW5nIHRlcm1zDQpmcm9tIE9BdXRoIDIuMCBidXQgd2l0aCBkaWZmZXJlbnQgZGVm aW5pdGlvbnMgbWF5IGxlYWQgdG8gdW5uZWNlc3NhcnkNCmNvbmZ1c2lvbi4gIElmIEkgdW5kZXJz dGFuZCBjb3JyZWN0bHksIGEgc2ltaWxhciByZWFzb25pbmcgcHJvbXB0ZWQgRGljayB0bw0KdXNl IHRoZSB0ZXJtICJHUyIgaW4gWEF1dGgsIHBpY2tpbmcgYSBuYW1lIHRoYXQgd2FzIG5vdCBhbHJl YWR5IHVzZWQgaW4NCk9BdXRoIDIuMC4NCg0KLUJlbg0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlz dA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QN ClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KLS0NClRYQXV0aCBtYWlsaW5nIGxpc3QN ClRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCi0tDQpUWEF1dGggbWFpbGluZyBsaXN0DQpU WEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg0KLS0NCkZyYW5jaXMgUG91YXRjaGENCkNv LUZvdW5kZXIgYW5kIFRlY2huaWNhbCBMZWFkDQphZG9yc3lzIEdtYkggJiBDby4gS0cNCmh0dHBz Oi8vYWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvDQo= From nobody Tue Aug 11 19:14:57 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 D68B63A0E8E for ; Tue, 11 Aug 2020 19:14:55 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 1iVTg0aWyFgI for ; Tue, 11 Aug 2020 19:14:54 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 BFCE83A0C3A for ; Tue, 11 Aug 2020 19:14:53 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 184so503587wmb.0 for ; Tue, 11 Aug 2020 19:14:53 -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=4fteMTPTV0fxDuc/Iv5CXXlSLEa/GFEj0U06JNkAXlA=; b=PHeuZUj51Ct1eSG6vpujO1gTW7Y2jSrg3hkWdhjavSjL3+vxVS4/IY4ytBDv+g3dqN RZ6aYGteH/4RRLSHVT7oyeSPMAqzmyEgxUUKg2d8Q64aFpkUGYOGFCZKKedChvWOOOsu s/AhcVvnTTq4ETuThyMxFFDGIARrcA6VW+Bbg= 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=4fteMTPTV0fxDuc/Iv5CXXlSLEa/GFEj0U06JNkAXlA=; b=PfcZoe5COrlwcjvbP5YRuA0hD1nCh+VjQ/T90tUDfLOSA5tOSzj9puxVWY6vgyvXF3 wOOa+cB0MQ6XGQMHpDU+BIgD8Scdo+G1tDLHLNcd5SjCCWDR1uHuv2EJvdIvIfq9G9j/ Xk+OnfZk3XV167bHhBxr24iOtdDCY03J9CHcSEg8DBubz22GHcLZq/22GBDIqIvrIQ+K 4kYjpYDGt3PzJWVyZ6tKB4Mwyt1NchXTZ0yC5k8Sb0itfuoxV//LNxnBOSJuElQCYRsN NyXbkCqGIJYTZ4p9804Eg7NOqit8CzXyjl11NM0Nicoby7DXl9XFo0W2+INWYXjLKMf5 vYdQ== X-Gm-Message-State: AOAM531mfe3sdBU2WCTVg0Ax/rypZsz/61vuoG8XFNyUDfmVriKkE+8e DeudzGpubEi6tGL+uYHbzf1jc96J8FuVKC8Nx6iQmw== X-Google-Smtp-Source: ABdhPJwwt+TZB6L2b+2Dim/Vs+OxBIvVPSaZNipft9Qzqey08O2jf/5M8DHpEaogYGjlsLufOaWiQ96ExalHxEL09jg= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr6198296wmj.8.1597198491964; Tue, 11 Aug 2020 19:14:51 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Francis Pouatcha Date: Tue, 11 Aug 2020 22:14:41 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bff46e05aca4c02a" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 02:14:56 -0000 --000000000000bff46e05aca4c02a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dick, I will use the university registration use case as an example to illustrate steps (1) and (7). +-----------+ +--------------+ +-----------+ +----+ +---------------------+ | Requestor | | Orchestrator | | RS | | GS | | Resource Controller | | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | is | | Staff | | Registr. App | | Server | | AS | | Student | +-----------+ +--------------+ +-----------+ +----+ +---------------------+ |(1) RegisterStudent(StudentId) | | | |---------------------->| | | | | |(2) RequestRecordIntent(RecordType,StudentId, | | OrchestratorId):AuthRequest[RecordType, StudentId] | |<-------------->| | | | | | | | | |(3) AuthZRequest(RecordType,StudentId ,OrchestratorId) | |--------------------------->| | | | | |(4) ConsentRequest(RecordType, | | | | OrchestratorId):Consent | | | |<-------------->| | |(5) AuthZ[RecordType,StudentId,OrchestratorId] | |<---------------------------| | | | | | | | |(2) RequestRecord(RecordType,StudentId ,OrchestratorId) | | :RecordOf[StudentId] | | | |<-------------->| | | |(7) Registered | | | | |<----------------------| | | | + + + + + Step (1) is the initial service request "RegisterStudent" sent by the university staff to the University registration application. Step (7) is the response to step (1), the notification of the university staff that the registration was successful. Best regards /Francis On Tue, Aug 11, 2020 at 7:38 PM Dick Hardt wrote: > Hi Francis, responses inline ... > > On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha wrote: > >> Hello Dick, >> >> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt wrote: >> >>> Hi Francis >>> >>> The user is an entity, not a role in the protocol in how I am defining >>> roles, so steps (1) and (7) are confusing to me on what is happening. >>> >> "Requestor" is the role (*was* User). So the UML participant refers to >> the role "Requestor" >> > > I still don't understand what is happening in (1) and (7) > > >> >> >>> I also think that (2) could be an extension to GNAP, rather than part o= f >>> the core protocol. >>> >> If you make it an extension, you hide. It shall rather be an optional, >> integral part of the protocol. >> > > Most deployments today accomplish (2) by the developer reading RS > documentation. > > I'm in favor of showing that step in an abstract diagram. But it is not > clear to me what the requirements for (2), and they may vary radically > across use cases, so putting it in the core document seems to be getting > ahead of ourselves. > > >> In some open banking designs, >> - the "Orchestrator/Negotiator/Client" will not know the AS to talk to >> unless the call (2). >> > > Have you put these use cases in the wiki? > > >> - the request (2) might result in an exemption, meaning no need for >> further authorization, allowing to skip (3, 4, 5) and even (6). >> > > Agreed. > >> =E1=90=A7 > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000bff46e05aca4c02a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dick,

I will use th= e university registration use case as an example to illustrate steps (1) an= d (7).

+-----------+=C2=A0 =C2=A0 =C2=A0 +---------= -----+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
| = Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
=
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is = UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2= =A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student<= /span>=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--= ------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------= +
=C2=A0 |(1) RegisterStudent(StudentId)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestR= ecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0Orche= stratorId):AuthRequest[RecordType,StudentId= ]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--------= ------>|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|--------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) Con= sentRequest(RecordType,
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Cons= ent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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=A0AuthZ[= RecordType,StudentId,OrchestratorId]
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

Step (1) is the initial service request "RegisterStudent&quo= t; sent by the=C2=A0university staff to the University registration applica= tion.

Step (7) is the response to step (1), the notification = of the university staff that the registration was successful.
<= div>
Best regards
/Francis

On Tue, Aug 11, 2020= at 7:38 PM Dick Hardt <dick.har= dt@gmail.com> wrote:
Hi Francis, responses inline ...=C2=A0
On = Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> wrote:

<= div dir=3D"ltr">
- the request (2) might res= ult in an exemption, meaning no need for further authorization, allowing to= skip (3, 4, 5) and even (6).

=
Agreed.
3D""=E1=90=A7


--
--000000000000bff46e05aca4c02a-- From nobody Tue Aug 11 20:39:58 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 A13873A0EC3 for ; Tue, 11 Aug 2020 20:39:56 -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 Uf4bMpkuWUTl for ; Tue, 11 Aug 2020 20:39:54 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 74D103A0EC1 for ; Tue, 11 Aug 2020 20:39:54 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id v12so632891ljc.10 for ; Tue, 11 Aug 2020 20:39:54 -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=CiE1SjZDmDsLp7GenoMguJCpqq3YCnPT4ZEAR7VPU40=; b=fO57yVnwsfrbQOT21iPqvseHX2/BaumDzx1ECjJCKT62Y+mYsY4sqP5Qdzb8Eottle lwCKa3khCB1Aq/CD1E0K/nQH1KcZ38gMbSzzBTT2a2RgWffoM9GEm9Eo3zm5cW6o0yz6 fbSZd2dj3b4EZOlss0MN+kgi5pPyL/iohNiW3Bh1OnPrqsnIcn2PlYC3oiGqysSrGY/M tspQR3tn+H3CwZvbR6KM0fCD97s7aVgHmH9l6lA3A448Svx+eBYWo/tPJc/kBKgZP1DM yaA/BQPJs5rhvk/dIMxN1tfPIakpNvWAFKg4xZZRMy3H/uFWoTttbRfeeIqGjWfqluja nOBw== 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=CiE1SjZDmDsLp7GenoMguJCpqq3YCnPT4ZEAR7VPU40=; b=QIzvVToS4KKLhM+f77vq3Z2QUXLKWVapmZLEQvenBuouc1g8iPBef+KbEiSDBzetBB IW1+6evpaw4E2zKqo8UIq2OmW/l/pj7Ma0gtvJ0CAagdBiMvYS5y7i3OFxzs1HfDXI3z jpe5ZMZWEeZdDOlWbqT2u5fmw7TGNkoQWOlb0t2JAc78JHQnNanBIYE7wfBJiUuieSC5 F4uZynvOz0tqbUzdJeTXcSgCI9OQCVn8eK+Oy8Zzm/6JNaoLToojf78FsvTIbobeAxqV PUcP75Jmq5cAdrLXFwje3lARcNi/2FoDl3aDSqK0s/rQHsku6wsO2NlR9SL0CVq8/CNI NogA== X-Gm-Message-State: AOAM533/lxq9GcVsjLf+BOKZmCJCNAwf2QM06x1wMHdfz6HAYBhhK+gA 3XORn4rAQQTwTKpmG80jKJfcwOuYx7fHJ4BajqM= X-Google-Smtp-Source: ABdhPJzct5sfVKuzZ7klw2jZI6MuY+DtCrII63babCgU5U8qHkbaCy6q/KZk36YSXCQnoqFtMH2bdm78oMADG61QSg0= X-Received: by 2002:a2e:865a:: with SMTP id i26mr4090530ljj.246.1597203592454; Tue, 11 Aug 2020 20:39:52 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 11 Aug 2020 20:39:16 -0700 Message-ID: To: Francis Pouatcha Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c326d605aca5f098" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 03:39:57 -0000 --000000000000c326d605aca5f098 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Francis (I'm assuming your second (2) should have been a (6) ) Am I correct that 1, 4, & 7 are human interactions, and 2, 3, 5, & 6 are part of the protocol? =E1=90=A7 On Tue, Aug 11, 2020 at 7:14 PM Francis Pouatcha wrote: > Hello Dick, > > I will use the university registration use case as an example to > illustrate steps (1) and (7). > > +-----------+ +--------------+ +-----------+ +----+ > +---------------------+ > | Requestor | | Orchestrator | | RS | | GS | | Resource > Controller | > | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | is > | > | Staff | | Registr. App | | Server | | AS | | > Student | > +-----------+ +--------------+ +-----------+ +----+ > +---------------------+ > |(1) RegisterStudent(StudentId) | | | > |---------------------->| | | | > | |(2) RequestRecordIntent(RecordType,StudentId, > | | OrchestratorId):AuthRequest[RecordType, > StudentId] > | |<-------------->| | | > | | | | | > | |(3) AuthZRequest(RecordType,StudentId > ,OrchestratorId) > | |--------------------------->| | > | | | |(4) > ConsentRequest(RecordType, > | | | | > OrchestratorId):Consent > | | | |<-------------->| > | |(5) AuthZ[RecordType,StudentId,OrchestratorId] > | |<---------------------------| | > | | | | | > | |(2) RequestRecord(RecordType,StudentId > ,OrchestratorId) > | | :RecordOf[StudentId] | | > | |<-------------->| | | > |(7) Registered | | | | > |<----------------------| | | | > + + + + + > > Step (1) is the initial service request "RegisterStudent" sent by > the university staff to the University registration application. > > Step (7) is the response to step (1), the notification of the university > staff that the registration was successful. > > Best regards > /Francis > > > On Tue, Aug 11, 2020 at 7:38 PM Dick Hardt wrote: > >> Hi Francis, responses inline ... >> >> On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha wrote: >> >>> Hello Dick, >>> >>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt wrote= : >>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the protocol in how I am defining >>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>> >>> "Requestor" is the role (*was* User). So the UML participant refers to >>> the role "Requestor" >>> >> >> I still don't understand what is happening in (1) and (7) >> >> >>> >>> >>>> I also think that (2) could be an extension to GNAP, rather than part >>>> of the core protocol. >>>> >>> If you make it an extension, you hide. It shall rather be an optional, >>> integral part of the protocol. >>> >> >> Most deployments today accomplish (2) by the developer reading RS >> documentation. >> >> I'm in favor of showing that step in an abstract diagram. But it is not >> clear to me what the requirements for (2), and they may vary radically >> across use cases, so putting it in the core document seems to be getting >> ahead of ourselves. >> >> >>> In some open banking designs, >>> - the "Orchestrator/Negotiator/Client" will not know the AS to talk to >>> unless the call (2). >>> >> >> Have you put these use cases in the wiki? >> >> >>> - the request (2) might result in an exemption, meaning no need for >>> further authorization, allowing to skip (3, 4, 5) and even (6). >>> >> >> Agreed. >> >>> =E1=90=A7 >> > > > -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ > --000000000000c326d605aca5f098 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Francis

(I'm assuming your s= econd (2) should have been a (6) )

Am I correct that= 1, 4, & 7 are human interactions, and 2, 3, 5, & 6 are part of the= protocol?

3D""=E1=90=A7
<= br>
On Tue,= Aug 11, 2020 at 7:14 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

I will use the university registration use case as an example to illu= strate steps (1) and (7).

+-----------+=C2=A0 =C2= =A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+-------= --------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2= =A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Con= troller |
| is UNIV-1 |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |= =C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Sta= ff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 = =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student<= /span>=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--= ------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------= +
=C2=A0 |(1) RegisterStudent(StudentId)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestR= ecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthReq= uest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(RecordTyp= e,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|--------------------------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0O= rchestratorId):Consent
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,OrchestratorId]
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordTy= pe,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-= ------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

Step (1) is the in= itial service request "RegisterStudent" sent by the=C2=A0universi= ty staff to the University registration application.

Step (7)= is the response to step (1), the notification of the university staff that= the registration was successful.

Best regards
/Francis


On Tue, Aug 11, = 2020 at 7:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis, respons= es inline ...=C2=A0

On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> wro= te:
Hello Dick,

On Tue, Aug 11, 2020 at 6:22 PM= Dick Hardt <d= ick.hardt@gmail.com> wrote:
Hi Francis

The user = is an entity, not a role in the protocol in how I am defining roles, so ste= ps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). So the UML = participant refers=C2=A0to the role "Requestor"
=

I still don't understand what is happe= ning in (1) and (7)
=C2=A0

<= /div>

I also think that (2) could be an extension to GNAP, rathe= r than part of the core protocol.
If you make = it an extension, you hide. It shall rather be an optional, integral part of= the protocol.

Most depl= oyments today accomplish (2) by the developer reading RS documentation.

I'm in favor of showing that step in an abstract = diagram. But it is not clear to me what the requirements for (2), and they = may vary radically across use cases, so putting it in the core document see= ms to be getting ahead of ourselves.
=C2=A0
In some open banking designs,=C2=A0
- the "Orchestra= tor/Negotiator/Client" will not know the AS to talk to unless the call= (2).

Have you put these = use cases in the wiki?
=C2=A0
- the = request (2) might result in an exemption, meaning no need for further autho= rization, allowing to skip (3, 4, 5) and even (6).

Agreed.
3D""=E1=90=A7


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--000000000000c326d605aca5f098-- From nobody Wed Aug 12 00:25:36 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 5D9183A10E7 for ; Wed, 12 Aug 2020 00:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 LKnFSKoA2xOx for ; Wed, 12 Aug 2020 00:25:33 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 781B13A10E4 for ; Wed, 12 Aug 2020 00:25:33 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id p13so820198ilh.4 for ; Wed, 12 Aug 2020 00:25:33 -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=9WhHoFW2JQ4ft1zFmvXtf+PpkVwqHc+1dUjJbl7+a/I=; b=q8uJokR0yQR2geLjZG9QKjTtr4ca897ZRTIZjGJVsKSx2ZO54WiwyN+C6HRtijXgGK +MZbrWmmPlXUEDFEc8yG8N/fCaFdcK8199Px7dvePhs7zOfFq/UyBPvgMYGQonI9rT+4 8zwEMZGUNhQylYV5kpAK0SxRQUiuLHausdK/jc4daj/X1p2x3/XtGRFMRx1wHgntqeDL K/W8IRSKDXM9+A2XIIpUU7CEbYDWSieUValkjuUNI+m21ystV3A3UxFHzSXGZI8/2uX+ FcDQBWP2dq3531/ydRlb77G9580HQOvUfJd99yj2d4ojqeRDh8hLCViKdLR1LmLyfvCz lXGg== 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=9WhHoFW2JQ4ft1zFmvXtf+PpkVwqHc+1dUjJbl7+a/I=; b=pcazKvvKvRSJMekkIdPzN+ibDvP3U2C+Q6YWTzh+HRWYpZJyANd1ozMtsYG4C7JgZM 24UES9CaLMrYjfq1EByn0b7O3LEbcuBc1qwRz9FDQo0WB7eRkfOjAFr/xhtSaWLVUiym 7BvwA5wAbPZA4J04+A64NGYkHozmD0/RJWxxlzaOyRr9Up+Yxz8y44V/DKwF3nvlbFbj umj4uTBpu8JSGwOgcM5DyvH+XlwZhS/nX6WwXtsflmfs51NxHKuyCpmppv2jOMGS9Ic5 W0j89s1s7BnDWESVVeUBbirvgzDrReCZmI4igI/QnvOJyF+5ds8rAdD6fygWDH/FUmUH G6aw== X-Gm-Message-State: AOAM532BpZrGWMq11awZXtxKRVnSUb/MP1wdSBPr8yt45+UbsIBR1Er6 h4EkejEuxFlDJYVOXs5951ePU201ArVWQsQ4QrA= X-Google-Smtp-Source: ABdhPJwdD9JNpjGNLFb05FshGFvMnQlGcSV1yR8o3X551tzLwy+z9mUIU99i5PW9pm8i+w9Y5pssIKr1T+kNuUOhXVI= X-Received: by 2002:a05:6e02:8:: with SMTP id h8mr24550900ilr.188.1597217132793; Wed, 12 Aug 2020 00:25:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 12 Aug 2020 09:25:21 +0200 Message-ID: To: Mike Jones Cc: Dick Hardt , Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000d4553805aca91726" Archived-At: Subject: Re: [GNAP] Design team formed 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: Wed, 12 Aug 2020 07:25:35 -0000 --000000000000d4553805aca91726 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, happy to contribute. Also interested to get a confirmation on the version of the docs to take as inputs. Cheers Fabien On Tue, Aug 11, 2020 at 10:11 PM Mike Jones wrote: > Thanks for letting me know. I=E2=80=99ll wait to print the copies I=E2= =80=99m going to > review until I see that the new version has been published. (I always do > my best cover-to-cover spec reviews by reading them on paper =E2=80=93 pr= eferably > outside in nice weather, away from other distractions.) > > > > -- Mike > > > > *From:* TXAuth *On Behalf Of *Dick Hardt > *Sent:* Tuesday, August 11, 2020 12:54 PM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; GNAP Mailing List < > txauth@ietf.org> > *Subject:* [GNAP] Design team formed > > > > Mike: I'm going to add in the updated terms I just posted to the list to > the XAuth ID later today. > > > > On Tue, Aug 11, 2020 at 10:02 AM Dick Hardt wrote: > > Leif / Yaron: thanks for organizing! > > > > Kathleen, Mike, Fabien: thanks for stepping up. > > > > Mike: I have a number of adjustments I had queued for a new version prior > to the WG meeting, but I did not think it was useful to push new concepts > or material given the path to have a design team. > > > > > > On Tue, Aug 11, 2020 at 9:14 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > Thanks for your confidence in me and the rest of the design team. I plan > to read both individual specs cover-to-cover as part of my preparation fo= r > this work. > > Dick and Justin, are there additional edits you plan to publish before I > should do my review, or should I review the currently published drafts? > > Thanks, > -- Mike > > -----Original Message----- > From: TXAuth On Behalf Of Yaron Sheffer > Sent: Tuesday, August 11, 2020 3:43 AM > To: GNAP Mailing List > Subject: [GNAP] Design team formed > > Thank you all for attending the inaugural GNAP meeting at IETF-108. We ha= d > quite a few volunteers, and the chairs picked the following people for th= e > design team: > > * Kathleen Moriarty > * Justin Richer > * Dick Hardt > * Mike Jones > * Fabien Imbault > > Kathleen has graciously agreed to convene the sessions and report on the > team's outcome. Thank you all who volunteered! > > We expect the design team to decide on a solution outline that combines > the best of both proposals, and present this outline by Sep. 15. Anything > is as usual subject to approval by the whole working group. > > Thanks, > Leif and Yaron > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d4553805aca91726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, happy to contribute.=C2=A0
Also interested to = get a confirmation on the version of the docs to take as inputs.
= Cheers
Fabien

 --000000000000d4553805aca91726-- From nobody Wed Aug 12 01:02:18 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 21A843A1124 for ; Wed, 12 Aug 2020 01:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 vPpBRYi8JO2p for ; Wed, 12 Aug 2020 01:02:13 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 C896A3A1123 for ; Wed, 12 Aug 2020 01:02:13 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id j8so1588374ioe.9 for ; Wed, 12 Aug 2020 01:02:13 -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=xX3ePYkvh6DHZ+F8aZvYk1xzWSByZxGLy1oJpGWA0Gs=; b=V/MaGHQL2CVBoGXSlwKFgtulmT+Jzc2q7cx4o8NNygHJRsvVr6m++0B/23tZdM3vV8 +rUi8rkExi+3bI8xUSBGy1Z0rNf/UDOg7bUIPfl0aU6DAKz6XdZ7blhXokD/KvSWOKZq NoJFpH34a/h8rD7w4dRcQ+koYB0kXwcSr0Hix5FcXJo6NcwZjyj3zehluyu/JzK8ICpt og3B9qSYnEfSjDS4+JusVhrQb1+wTR7O2OzMtGBq5vajJTEPQiay+6VvsCNI5d1JEby3 6EMdZyseK3F6gUM0/eYifyZF4eeYnTlyVrxKjsimJc6aOUeNHsRNX4wFu76//eg6pT04 eZQQ== 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=xX3ePYkvh6DHZ+F8aZvYk1xzWSByZxGLy1oJpGWA0Gs=; b=JdYUF7AKGcL1VgKyYgSI0gIFokVUxXfxBLixg3V0hTF/7PC7AV6CIwG9oXlkJRHqL4 gKts73TsQApzPQnTIslxx4WrSwmCXYTCnDiMcYdYaN5HRCPVimFvuOnaq8gC32QVQyXb anm5A180laZlQEAFCgApNQ6bc74zlTL0msc4EsGW1NJWeOOo7UWpyZQN9ferccnDzCu0 hg3nYXqRo5EI7fu+yDuSJcVa4vxtluA11ozTySPlDi174xOFXgrdC8yTXqB+bfnMWQ7n y3VVreDdACZxNON4e6x+Bm21FugPBBueKuJjYoR/FKYToH/Z7apU9+8RkhjWUUiqm3NG EfpQ== X-Gm-Message-State: AOAM530U2tliKaHgdq5Mb/f+012fDdiNKeGRJeaHw34EPRgrfSV/0Uxy xmBj3LuMFphShSsBMEyTLWeG3n+GLwepdquAmlkJLOD8EY4= X-Google-Smtp-Source: ABdhPJwpYon3K+l8AlkrA9lPOLHg1XZhdV5ecZRgLzXxCWZGMLHHEYOKmD7WH929pCr8Di4TnwrDvj4/0uBy1HF5cLM= X-Received: by 2002:a5d:841a:: with SMTP id i26mr26277137ion.144.1597219332891; Wed, 12 Aug 2020 01:02:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 12 Aug 2020 10:02:01 +0200 Message-ID: To: Francis Pouatcha Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000f7342b05aca99a50" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 08:02:16 -0000 --000000000000f7342b05aca99a50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis, My comments are embedded into your email with FI. You're saying in a follow-up message: "- If you want privacy, *don't* expose RS identity to AS. - If you want transparency, expose RS identity to AS. You can't have both...." While that may seem a reasonable dichotomy at first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system. Cheers, Fabien On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha wrote: > Hello Fabian, > > On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault > wrote: > >> Hi Francis, >> >> I think Denis points to the fact that, in the current situation, the AS >> receives the resource request from the Client and therefore knows what >> tokens are asked. >> > The token request must not mention any reference of the RS. > FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case on directed tokens, which is an interesting topic which makes sense in many scenarios. But as soon as you include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default. Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe. > >> Then it also implements the consent interface (and possibly the login >> too) and so it also knows who validates and what is accepted or not. >> > Decoupling this does not change the privacy context, as the AS issues the > Token. AS needs to add a reference to the RC in the token. SO AS can > correlate on StudentId anyway. > FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token. Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID. As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO. What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements =3D> the IS knows what information is used, bu= t the IS may be chosen by the IS independently from the AS or even run by the Client itself. In this case, suppose the RO only provided consent for rs_domain/directory1 for read. We now need to get back to the AS to mint the access token. If we want the AS to not know about the RS, we either : - don't supply the rs_domain at all -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization applies. In that case I agree with your either or statement. - or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized. Either way, the AS has not been provided any information as to where this token will effectively be used. > > >> I don't think the abstract flow deals with those privacy concerns. >> > To solve the privacy problem addressed in this thread, we need to go the > (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC > (Verifiable Credential) to the Student (in his role of RC). The Student > will then present this claim to UNIV-1 during his registration. In this > case we need no Grant negotiation and no AS. > FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation is still required for more general settings of authorization. I've added a DID example to my implementation, will publish it soon. > Best regards. > /Francis > >> > >> >> Then I agree with you on the audience field of the token, if left empty >> it simplifies part of the problem, although it removes a big part of the >> control you may want from directed tokens. That's why I'm willing to bet= ter >> develop the RS hiding idea. >> >> Fabien >> >> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >> >>> Hello Denis, >>> >>> what you describe in the use case seems to be the default behavior of >>> the protocol. Let me map it with this abstract protocol flow: >>> >>> +-----------+ +--------------+ +-----------+ +----+ >>> +---------------------+ >>> | Requestor | | Orchestrator | | RS | | GS | | Resource >>> Controller | >>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>> is | >>> | Staff | | Registr. App | | Server | | AS | | >>> Student | >>> +-----------+ +--------------+ +-----------+ +----+ >>> +---------------------+ >>> |(1) RegisterStudent | | | = | >>> |---------------------->| | | = | >>> | |(2) RequestRecordIntent(RecordType,StudentId= , >>> | | >>> OrchestratorId):AuthRequest[RecordType,StudentId] >>> | |<-------------->| | = | >>> | | | | = | >>> | |(3) >>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>> | |--------------------------->| = | >>> | | | |(4) >>> ConsentRequest(RecordType, >>> | | | | >>> OrchestratorId):Consent >>> | | | |<--------------= >| >>> | |(5) AuthZ[RecordType,StudentId,OrchestratorI= d] >>> | |<---------------------------| = | >>> | | | | = | >>> | |(2) >>> RequestRecord(RecordType,StudentId,OrchestratorId) >>> | | :RecordOf[StudentId] | = | >>> | |<-------------->| | = | >>> |(7) Registered | | | = | >>> |<----------------------| | | = | >>> + + + + = + >>> >>> we assume the authz request sent by "Client" to "AS" describes the >>> protected resource without referring to the authz server. An AS can iss= ue >>> the authz to release the graduation record of a student >>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference= to >>> the target university. >>> >>> What matters for this authz object is: >>> - StudentId: a reference to the student as known to the resource server= . >>> - RecordType: a reference to a resource of type graduation record as >>> understandable by the resource server. >>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>> authz to Orchestrator. >>> >>> But: >>> - RS must trust AS issued token. >>> - StudentId must be known to RS, AS and Orchestrator. >>> >>> Therefore, the AS does not need to know the RS. Keep the audience field >>> empty. >>> >>> Same principle applies for the second use case. >>> >>> What privacy problem do you see here? >>> >>> Best regards. >>> /Francis >>> >>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>> >>>> I tried my best twice to download three use cases in the Use cases >>>> directory, but I failed. >>>> >>>> Rather than failing a third time, here is the direct link of the secon= d >>>> try: >>>> >>>> >>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-c= ases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>> >>>> Denis >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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/ >>> -- >>> 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/ > --000000000000f7342b05aca99a50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis,=C2=A0

My c= omments are embedded into your email with FI.

You&= #39;re saying in a follow-up message:=C2=A0
"- If you want p= rivacy,=C2=A0don't=C2=A0expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can= 9;t have both...."
While that may seem=C2=A0a reasonab= le=C2=A0dichotomy=C2=A0at first sight, I believe the reality is actually mo= re nuanced and depends on how we end up designing the system.=C2=A0

Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:= 27 PM Francis Pouatcha <fpo@adorsys.de= > wrote:
=
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17= AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that= , in the current situation, the AS receives the resource request from the C= lient and therefore knows what tokens are asked.
<= div>The token request must not mention any reference of the RS.
=

FI : yes we can do that, but as Tom = commented, it's not a general rule. And for instance in XYZ you do desc= ribe the URL of the resource. See also the use case=C2=A0on directed tokens= , which is an interesting topic which makes sense in many scenarios.=C2=A0= =C2=A0
But as soon as you include that possibility, it's fair= to think that this capability could be used for surveillance purposes in s= ome cases, unless you found a privacy by design scheme that applies by defa= ult.=C2=A0=C2=A0
Again this doesn't mean that transparency re= quirements aren't important too, but I think there are other ways it ca= n be achieved (for instance, an inspiration is the certificate transparency= project). Could be an extension to the protocol I believe.=C2=A0

=C2=A0
Then it also impl= ements the consent interface (and possibly the login too) and so it also kn= ows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the = Token. AS needs to add a reference to the=C2=A0RC in the token. SO AS can c= orrelate on StudentId anyway.

=
FI : I disagree. It does change the privacy context, if as Denis sugge= sted, the consent is made outside of the AS and if you don't send to th= e AS the information on the RS when it needs to issue the token.
= Correlation on StudentId is limited as long as it's a local identifier,= i.e. not a public DID.=C2=A0

 --000000000000f7342b05aca99a50-- From nobody Wed Aug 12 01:22:23 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 145753A11B1 for ; Wed, 12 Aug 2020 01:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 DI_ZUsYOvwg4 for ; Wed, 12 Aug 2020 01:22:12 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 90F9F3A1194 for ; Wed, 12 Aug 2020 01:22:05 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id s189so1729793iod.2 for ; Wed, 12 Aug 2020 01:22:05 -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=JXztcq0s88gFcum8dc9cN/I5u7ZVYb/QpM1fzAYeu+o=; b=pP49AioBgm2INKbSXrobCKpZr5AXw/RmdfxuM7TdccIULUO5Ok4xtpP22IRuYtIbYB igkAopj2gP+FB0yJkR2vrUCIESuGZQRBfP69NcZIXE7cGYsIQE5tMDJ4DcFBrg260RL1 761Af/hujfdIL16OJSRUaetjq8qRaTY5GeIhZ8QD2rUmWsS1NgmXqaeSIwfewN4ce06H aWyo5b8kV9fzeYgT8nlwYcDYi0no5yX/CTEnPe2vltWwrdMrERm7ouo2HUcfgaodrw0l giZqiubf6duPbHQIyudhN5TIebC2P1UV2PTXcIP61SaQaPkwZv0kYArrcKbUTlSEC71r TeMg== 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=JXztcq0s88gFcum8dc9cN/I5u7ZVYb/QpM1fzAYeu+o=; b=LN1oHcTtdjynC2bNTsQ8l4x3vVPVZ5fju20d5Re8TZLiuTJcIHhhPLd7lsC6H3yjbr S+tGi774aWUJuR75AI9ulGlVxxV9VGpw0i8NEvoNj6yuh9ed5/U263ajd27hPy13SKZk c4yWKqivcxLeUCU6Gs5cqgdM8y08WFeFssPRuyzOPkyi3Tzp9HlHRsbccIcXukwERaNs 1ehiUhmugO7aY1UaiM0SvujR/QSBVM1C8vVcNUSHeK0ZdzF4isgNOhyqZTQEuuq07DeJ InyDM7oe6dcwhx3Q+MxfzGRq5qTgAwEwisvGlIIjsycGVmxHTJJpVySYTOunV5G8B5L+ a7nA== X-Gm-Message-State: AOAM531cuTk9CeYWtNH1VJKJ/sDPimEptoKP/5Unhm1enIAbK2GYl5pO OfB5YYSu/KgTSqti34hleZcxA42vWvHY4tqvC0E= X-Google-Smtp-Source: ABdhPJxJ6rUblZ4JEfbhw8pmrSQpxap9zCaIbWSSvlYo2jVZrqu2ktes37XEREdkIGgEUYBjJqyVlgRm/YQjpwfqSLY= X-Received: by 2002:a02:7092:: with SMTP id f140mr30729088jac.8.1597220524748; Wed, 12 Aug 2020 01:22:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 12 Aug 2020 10:21:53 +0200 Message-ID: To: Francis Pouatcha Cc: Tom Jones , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000001927605aca9e235" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 08:22:21 -0000 --00000000000001927605aca9e235 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 on support for SSI, which I believe the charter includes (e.g. "Verified Credentials"). Maybe not in the core (?) but at least as an extension. Also interested in how you imagine the AS on the user's device, which I believe is yet a separated topic from SSI (even is that could be an enabler). Cheers, Fabien On Wed, Aug 12, 2020 at 12:47 AM Francis Pouatcha wrote: > Hello Tom, > > On Tue, Aug 11, 2020 at 6:42 PM Tom Jones > wrote: > >> I guess I need to ask the group as a whole then. >> Will GNAP support self-issued Identifiers? >> If so then the AS is on the user's device. >> I need to understand that SII are in-scope. >> Peace ..tom >> > I hope GNAP will be designed to support SII. If you could drop some use > cases here: https://github.com/ietf-wg-gnap/general/wiki > >> >> >> On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha wrote: >> >>> On Tue, Aug 11, 2020 at 6:27 PM Tom Jones >>> wrote: >>> >>>> "The token request must not mention any reference of the RS." >>>> this cannot be an absolute rule. I have cases were the client needs to >>>> tell the user which they are coming back for additional grants. >>>> The reason is typically because a request by the client for data/acces= s >>>> from the rs was rejected. The reason for the rejection is important fo= r the >>>> client to make the case to the user for additional permissions. >>>> Peace ..tom >>>> >>> - If you want privacy, *don't* expose RS identity to AS. >>> - If you want transparency, expose RS identity to AS. >>> You can't have both.... >>> /Francis >>> >>>> >>>> >>>> >>>> On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha >>> 40adorsys.de@dmarc.ietf.org> wrote: >>>> >>>>> Hello Fabian, >>>>> >>>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I think Denis points to the fact that, in the current situation, the >>>>>> AS receives the resource request from the Client and therefore knows= what >>>>>> tokens are asked. >>>>>> >>>>> The token request must not mention any reference of the RS. >>>>> >>>>> >>>>>> Then it also implements the consent interface (and possibly the logi= n >>>>>> too) and so it also knows who validates and what is accepted or not. >>>>>> >>>>> Decoupling this does not change the privacy context, as the AS issues >>>>> the Token. AS needs to add a reference to the RC in the token. SO AS = can >>>>> correlate on StudentId anyway. >>>>> >>>>> >>>>>> I don't think the abstract flow deals with those privacy concerns. >>>>>> >>>>> To solve the privacy problem addressed in this thread, we need to go >>>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to is= sue a >>>>> VC (Verifiable Credential) to the Student (in his role of RC). The St= udent >>>>> will then present this claim to UNIV-1 during his registration. In th= is >>>>> case we need no Grant negotiation and no AS. >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>>> >>>>> >>>>>> >>>>>> Then I agree with you on the audience field of the token, if left >>>>>> empty it simplifies part of the problem, although it removes a big p= art of >>>>>> the control you may want from directed tokens. That's why I'm willin= g to >>>>>> better develop the RS hiding idea. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>>> >>>>>>> Hello Denis, >>>>>>> >>>>>>> what you describe in the use case seems to be the default behavior >>>>>>> of the protocol. Let me map it with this abstract protocol flow: >>>>>>> >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>>> Resource Controller | >>>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>>> is | >>>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>>> Student | >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> |(1) RegisterStudent | | | >>>>>>> | >>>>>>> |---------------------->| | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>>> | | >>>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(3) >>>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>>> | |--------------------------->| >>>>>>> | >>>>>>> | | | |(4) >>>>>>> ConsentRequest(RecordType, >>>>>>> | | | | >>>>>>> OrchestratorId):Consent >>>>>>> | | | >>>>>>> |<-------------->| >>>>>>> | >>>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>>> | |<---------------------------| >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>>> | | :RecordOf[StudentId] | >>>>>>> | >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> |(7) Registered | | | >>>>>>> | >>>>>>> |<----------------------| | | >>>>>>> | >>>>>>> + + + + >>>>>>> + >>>>>>> >>>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>>> protected resource without referring to the authz server. An AS can= issue >>>>>>> the authz to release the graduation record of a student >>>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refer= ence to >>>>>>> the target university. >>>>>>> >>>>>>> What matters for this authz object is: >>>>>>> - StudentId: a reference to the student as known to the resource >>>>>>> server. >>>>>>> - RecordType: a reference to a resource of type graduation record a= s >>>>>>> understandable by the resource server. >>>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bin= d >>>>>>> authz to Orchestrator.. >>>>>>> >>>>>>> But: >>>>>>> - RS must trust AS issued token. >>>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>>> >>>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>>> field empty. >>>>>>> >>>>>>> Same principle applies for the second use case. >>>>>>> >>>>>>> What privacy problem do you see here? >>>>>>> >>>>>>> Best regards. >>>>>>> /Francis >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>>> >>>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>>> directory, but I failed. >>>>>>>> >>>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>>> second try: >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-u= se-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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/ >>>>>>> -- >>>>>>> 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/ >>>>> -- >>>>> 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/ > --00000000000001927605aca9e235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on support for SSI, which I believe the charter in= cludes (e.g. "Verified Credentials").=C2=A0=C2=A0
Maybe not = in the core (?) but at least as an extension.=C2=A0
=C2=A0
Als= o interested in how you imagine the AS on the user's device, which I be= lieve is yet a separated topic from SSI (even is that could be an enabler).=

Cheers,
Fabien=C2=A0
<= /div>
O= n Wed, Aug 12, 2020 at 12:47 AM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Tom,
On Tu= e, Aug 11, 2020 at 6:42 PM Tom Jones <thomasclinganjones@gmail.com> wrote:=
I guess I need to ask the group as a whole then.
Will GNAP support se= lf-issued Identifiers?
If so then the AS is on the user's dev= ice.
I need to understand that SII are in-scope.
Peace ..tom
<= /div>
I hope GNAP will be designed to support = SII. If you could drop some use cases here:=C2=A0https://github.com/ietf-wg= -gnap/general/wiki=C2=A0


On Tue, Aug 11, 2020 at 3:40 PM = Francis Pouatcha <fp= o@adorsys.de> wrote:
On Tue, Aug 11, 2020 at 6:27 = PM Tom Jones <thomasclinganjones@gmail.com> wrote:
"The token request mu= st not mention any reference of the RS."
this cannot be an a= bsolute rule. I have cases were the client needs to tell the user which the= y are coming back for additional grants.
The reason is typically = because a request by the client for data/access from the rs was rejected. T= he reason for the rejection is important for the client to make the case to= the user for additional permissions.
Peace ..tom
- If you want privacy, don't exp= ose RS identity to AS.
- If you want transparency, expose RS iden= tity to AS.
You can't have both....
/Francis=C2=A0<= /div>


On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ie= tf.org> wrote:
Hello Fabian,

On Tue, Aug 11, 2020= at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,
I think Denis points to the fact = that, in the current situation, the AS receives the resource request from t= he Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.
=C2=A0
Then it also implements the consent interface (= and possibly the login too) and so it also knows who validates and what is = accepted or not.
Decoupling this does not chan= ge the privacy context, as the AS issues the Token. AS needs to add a refer= ence to the=C2=A0RC in the token. SO AS can correlate on StudentId anyway.<= /div>


I don't thin= k the abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thread, we ne= ed to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to= issue a VC (Verifiable Credential) to the Student (in his role of RC). The= Student will then present this claim to UNIV-1 during his registration. In= this case we need no Grant negotiation and=C2=A0no AS.

Best regards.
/Francis
=C2=A0
<= div dir=3D"auto">
Then I agree with you on the a= udience field of the token, if left empty it simplifies part of the problem= , although it removes a big part of the control you may want from directed = tokens. That's why I'm willing to better develop the RS hiding idea= .=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dma= rc.ietf.org> a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,

what you describe in the use case seems to be the default behavior of th= e protocol. Let me map it with this abstract protocol flow:

<= /div>
+-----------+=C2=A0 =C2=A0 =C2=A0 += --------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+-------------------= --+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |= =C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
|=C2=A0 =C2=A0Staff=C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |= =C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 = =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0= +-----------+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) Reg= isterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0OrchestratorId):AuthRequest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRe= quest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0O= rchestratorId):Consent
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,OrchestratorId]
=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<---------------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,StudentId,O= rchestratorId)
=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

we assume the authz request sent by "Client" to = "AS" describes the protected resource without referring=C2=A0to t= he authz server. An AS can issue the authz to release the graduation record= =C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,StudentId,OrchestratorId]), = without any reference to the target university.=C2=A0

What ma= tters for this authz object is:
-= StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resou= rce of type graduation record as understandable=C2=A0 by the resource serve= r.
-=C2=A0OrchestratorId: referen= ce to the Orchestrator. Can be used to bind authz to Orchestrator..<= /div>

But:
- RS must trust AS is= sued token.
-=C2=A0StudentId must= be known to RS, AS and=C2=A0Orchestrator.

Therefore, the AS = does not need to know the RS. Keep the audience field empty.

= Same principle applies for the second use case.

What privacy = problem do you see here?

Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Den= is <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis







--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>


--
--
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
--00000000000001927605aca9e235-- From nobody Wed Aug 12 04:52:01 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 31A9C3A0F94 for ; Wed, 12 Aug 2020 04:51:59 -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 LF8fa4davV30 for ; Wed, 12 Aug 2020 04:51:56 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 703F93A0F93 for ; Wed, 12 Aug 2020 04:51:56 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id f1so1759315wro.2 for ; Wed, 12 Aug 2020 04:51:56 -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=KOx957G7zjgBaSt12/HUHucCtNjAolzAhbSa8pDZ3uE=; b=TmT3zCHe+PJvh6KzcKVidJuJT6G975TAkFl6Lw5vxCKDnpABRcTP6g5fe624hl12YX lQBIBIhPVf5WYUT9zb7AahZHC19Gb0sWE0nMGrtLM/VE6M/xE23oHz71gDbBz9y/XjK2 xHhf3QvCBkKeq46cOJ0k0TtsXIIDNXzZya4Bo= 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=KOx957G7zjgBaSt12/HUHucCtNjAolzAhbSa8pDZ3uE=; b=Qnq+eaegoFzkhec1+keJ083AXb0tYsJL+Xg4wPtOP90VC9fCJfQa7Ff9XKr27RvzeI uRnw0PcKMOrhDa6Z99zEjqyi/C2IS0x+mHtUQknCJ+g/5AJn+E1vvxh+JfaZ6Kk+4fU5 VZQmP3fPEtix42RZI8cmeysKxZG3gnHPkpO+Bcc4Hg/Pu3wIt4ZweJkyBmmAOkBjL40U 2caK3o7HecnW0noLtmzkeL8OgTuVPiODF7oNPmtKKDfdEJfG6WJIlAgnpgzqa6zIiwBy Tz9LmuHEwLtYZRo8o0MqYIgt141ynCzd8ZW3EG7bKmbOssqNR7qgtJq6f9eG08PeJyd5 uxPQ== X-Gm-Message-State: AOAM5332gGuuxMF5XqaitH36lg2FbLEnc2bNS7u4s4V6D7sXDvn1UNZB TJX740vUzeKPU2lcsWIL6gtxiRIWflZX9ElEqhJdVg== X-Google-Smtp-Source: ABdhPJx2+yV6L55gs5nEfvkssrqx6Sgr5bSx8B6deoggV2aXxMG3JeS8o6JVbTctMIC2bhWg7zj+xOoW5ALzBBkJQvE= X-Received: by 2002:a5d:4a41:: with SMTP id v1mr36434260wrs.371.1597233114635; Wed, 12 Aug 2020 04:51:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Wed, 12 Aug 2020 07:51:43 -0400 Message-ID: To: Fabien Imbault Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006bf6d405acacd0d2" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 11:51:59 -0000 --0000000000006bf6d405acacd0d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Fabian, inline On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault wrote: > Hi Francis, > > My comments are embedded into your email with FI. > > You're saying in a follow-up message: > "- If you want privacy, *don't* expose RS identity to AS. > - If you want transparency, expose RS identity to AS. > You can't have both...." > While that may seem a reasonable dichotomy at first sight, I believe the > reality is actually more nuanced and depends on how we end up designing t= he > system. > > Cheers, > Fabien > > On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha wrote: > >> Hello Fabian, >> >> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault >> wrote: >> >>> Hi Francis, >>> >>> I think Denis points to the fact that, in the current situation, the AS >>> receives the resource request from the Client and therefore knows what >>> tokens are asked. >>> >> The token request must not mention any reference of the RS. >> > > FI : yes we can do that, but as Tom commented, it's not a general rule. > And for instance in XYZ you do describe the URL of the resource. See also > the use case on directed tokens, which is an interesting topic which make= s > sense in many scenarios. > Yes. But disclosing the protected resource discloses the RS. But as soon as you include that possibility, it's fair to think that this > capability could be used for surveillance purposes in some cases, unless > you found a privacy by design scheme that applies by default. > Yes. THen default shall be using URI of resource description and not URL to indicate resource location. Again this doesn't mean that transparency requirements aren't important > too, but I think there are other ways it can be achieved (for instance, a= n > inspiration is the certificate transparency project). Could be an extensi= on > to the protocol I believe. > The certificate transparency deals with something else. Does not fit in this context at all. > > >> >>> Then it also implements the consent interface (and possibly the login >>> too) and so it also knows who validates and what is accepted or not. >>> >> Decoupling this does not change the privacy context, as the AS issues th= e >> Token. AS needs to add a reference to the RC in the token. SO AS can >> correlate on StudentId anyway. >> > > FI : I disagree. It does change the privacy context, if as Denis > suggested, the consent is made outside of the AS and if you don't send to > the AS the information on the RS when it needs to issue the token. > Correlation on StudentId is limited as long as it's a local identifier, > i.e. not a public DID. > How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore. > > As a concrete example: a user may want to use an application to access > rs_domain/directory1 and rs_domain/directory2 in read and write, which ar= e > managed by a RO. > What I suggested is that the Client may (optionally) carry out its consen= t > through a decoupled IS server (separated from the AS), that displays the = UI > based on the RS requirements =3D> the IS knows what information is used, = but > the IS may be chosen by the IS independently from the AS or even run by t= he > Client itself. > What do you need an AS for? Then it can sign the claim to present to RS. > In this case, suppose the RO only provided consent for > rs_domain/directory1 for read. > We now need to get back to the AS to mint the access token. > If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors. > If we want the AS to not know about the RS, we either : > - don't supply the rs_domain at all -> the JWT says that directory1 in > read access is authorized. The downside is that we actually cannot contro= l > to which URL the authorization applies. In that case I agree with your > either or statement. > Yes > - or find a way to hide it (not sure if that's practical, hence my > questions on RS hiding). This would have the benefit of still allowing > directed tokens -> the JWT says that rs_petname/directory1 in read access > is authorized. > More complexity. > > Either way, the AS has not been provided any information as to where this > token will effectively be used. > >> >>> I don't think the abstract flow deals with those privacy concerns. >>> >> To solve the privacy problem addressed in this thread, we need to go the >> (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a V= C >> (Verifiable Credential) to the Student (in his role of RC). The Student >> will then present this claim to UNIV-1 during his registration. In this >> case we need no Grant negotiation and no AS. >> > > FI : That may be useful but it's not enough. What you describe only works > because you take a very specific use case, aka registration. This fits we= ll > into DID/VC without requiring authorization per say. However grant > negotiation is still required for more general settings of authorization. > Please drop the next use case in the repo, so we can dive deeper into it and see how to provide both central grant negotiation and privacy. I've added a DID example to my implementation, will publish it soon. > > >> Best regards. >> /Francis >> >>> >> >>> >>> Then I agree with you on the audience field of the token, if left empty >>> it simplifies part of the problem, although it removes a big part of th= e >>> control you may want from directed tokens. That's why I'm willing to be= tter >>> develop the RS hiding idea. >>> >>> Fabien >>> >>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>> >>>> Hello Denis, >>>> >>>> what you describe in the use case seems to be the default behavior of >>>> the protocol. Let me map it with this abstract protocol flow: >>>> >>>> +-----------+ +--------------+ +-----------+ +----+ >>>> +---------------------+ >>>> | Requestor | | Orchestrator | | RS | | GS | | Resource >>>> Controller | >>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>> is | >>>> | Staff | | Registr. App | | Server | | AS | | >>>> Student | >>>> +-----------+ +--------------+ +-----------+ +----+ >>>> +---------------------+ >>>> |(1) RegisterStudent | | | >>>> | >>>> |---------------------->| | | >>>> | >>>> | |(2) RequestRecordIntent(RecordType,StudentI= d, >>>> | | >>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>> | |<-------------->| | >>>> | >>>> | | | | >>>> | >>>> | |(3) >>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>> | |--------------------------->| >>>> | >>>> | | | |(4) >>>> ConsentRequest(RecordType, >>>> | | | | >>>> OrchestratorId):Consent >>>> | | | >>>> |<-------------->| >>>> | >>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>> | |<---------------------------| >>>> | >>>> | | | | >>>> | >>>> | |(2) >>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>> | | :RecordOf[StudentId] | >>>> | >>>> | |<-------------->| | >>>> | >>>> |(7) Registered | | | >>>> | >>>> |<----------------------| | | >>>> | >>>> + + + + >>>> + >>>> >>>> we assume the authz request sent by "Client" to "AS" describes the >>>> protected resource without referring to the authz server. An AS can is= sue >>>> the authz to release the graduation record of a student >>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any referenc= e to >>>> the target university. >>>> >>>> What matters for this authz object is: >>>> - StudentId: a reference to the student as known to the resource serve= r. >>>> - RecordType: a reference to a resource of type graduation record as >>>> understandable by the resource server. >>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>> authz to Orchestrator. >>>> >>>> But: >>>> - RS must trust AS issued token. >>>> - StudentId must be known to RS, AS and Orchestrator. >>>> >>>> Therefore, the AS does not need to know the RS. Keep the audience fiel= d >>>> empty. >>>> >>>> Same principle applies for the second use case. >>>> >>>> What privacy problem do you see here? >>>> >>>> Best regards. >>>> /Francis >>>> >>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>> >>>>> I tried my best twice to download three use cases in the Use cases >>>>> directory, but I failed. >>>>> >>>>> Rather than failing a third time, here is the direct link of the >>>>> second try: >>>>> >>>>> >>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-= cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>> >>>>> Denis >>>>> >>>>> >>>>> -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000006bf6d405acacd0d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM F= abien Imbault <fabien.imbaul= t@gmail.com> wrote:
Hi Francis,=C2=A0

My comments are embedded into your email with FI.

You're saying in a follow-up message:=C2=A0
"- If= you want privacy,=C2=A0don't=C2=A0expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem=C2= =A0a reasonable=C2=A0dichotomy=C2=A0at first sight, I believe the reality i= s actually more nuanced and depends on how we end up designing the system.= =C2=A0

Cheers,
Fabien

On Tue, Aug 1= 1, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fa= bian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com>= wrote:
Hi Francis,

I think = Denis points to the fact that, in the current situation, the AS receives th= e resource request from the Client and therefore knows what tokens are aske= d.
The token request must not mention any ref= erence of the RS.

FI : ye= s we can do that, but as Tom commented, it's not a general rule. And fo= r instance in XYZ you do describe the URL of the resource. See also the use= case=C2=A0on directed tokens, which is an interesting topic which makes se= nse in many scenarios.=C2=A0=C2=A0
Yes. = But disclosing the protected resource discloses the RS.=C2=A0
<= div class=3D"gmail_quote">
But as soon as you include that possibility,= it's fair to think that this capability could be used for surveillance= purposes in some cases, unless you found a privacy by design scheme that a= pplies by default.=C2=A0
Yes. THen defau= lt shall be using URI of resource description and not URL to indicate resou= rce location.=C2=A0

Again this = doesn't mean that transparency requirements aren't important too, b= ut I think there are other ways it can be achieved (for instance, an inspir= ation is the certificate transparency project). Could be an extension to th= e protocol I believe.=C2=A0
The certific= ate transparency deals with something else. Does not fit in this context at= all.
=C2=A0

=C2=A0
Then it also implements the consent inter= face (and possibly the login too) and so it also knows who validates and wh= at is accepted or not.
Decoupling this does no= t change the privacy context, as the AS issues the Token. AS needs to add a= reference to the=C2=A0RC in the token. SO AS can correlate on StudentId an= yway.

FI : I disagree. It= does change the privacy context, if as Denis suggested, the consent is mad= e outside of the AS and if you don't send to the AS the information on = the RS when it needs to issue the token.
Correlation on StudentId= is limited as long as it's a local identifier, i.e. not a public DID.= =C2=A0
How local can the StudentId be? I= t is known to both universities and to the AS. Without a public reference, = you can not link information between unrelated entities (AS, UNIV-0 and UNI= V-1). Using VCs can help here. Then you do not need central AS anymore.

As a concrete example: a user may = want to use an application to access rs_domain/directory1 and rs_domain/dir= ectory2 in read and write, which are managed by a RO.=C2=A0
What = I suggested is that the Client may (optionally) carry out its consent throu= gh a decoupled IS server (separated from the AS), that displays the UI base= d on the RS requirements =3D> the IS knows what information is used, but= the IS may be chosen by the IS independently from the AS or even run by th= e Client itself.=C2=A0
What do you need = an AS for? Then it can sign the claim to present to RS.
=C2=A0
In this case, suppose the RO only provided conse= nt for rs_domain/directory1 for read.=C2=A0
We now need to get ba= ck to the AS to mint the access token.=C2=A0
=
If AS mint access token, AS will be able to correlate. Unless start ap= plying intransparent complex reference mapping techniques, wich might even = open room for new attack vectors.


If we want the AS to not know about the RS, we either := =C2=A0
- don't supply the rs_domain at all -> the JWT says= that directory1 in read access is authorized. The downside is that we actu= ally cannot control to which URL the authorization=C2=A0applies. In that ca= se I agree with your either or statement.=C2=A0=C2=A0
Yes=C2=A0
- or find a way to hid= e it (not sure if that's practical, hence my questions on RS hiding). T= his would have the benefit of still allowing directed tokens -> the JWT = says that rs_petname/directory1 in read access is authorized.
More complexity.=C2=A0
= =C2=A0
Either way, the AS has not been provided any information a= s to where this token will effectively be used.=C2=A0=C2=A0


I don't think the abstract flow deals= with those privacy concerns.=C2=A0
To solve t= he privacy problem addressed in this thread, we need to go the (SSI/DiD/VC)= way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable C= redential) to the Student (in his role of RC). The Student will then presen= t this claim to UNIV-1 during his registration. In this case we need no Gra= nt negotiation and=C2=A0no AS.

FI : That may be useful but it's not enough. What you describe on= ly works because you take a very specific use case, aka registration. This = fits well into DID/VC without requiring authorization per say. However gran= t negotiation=C2=A0is still required for more general settings of authoriza= tion.=C2=A0=C2=A0
Please drop the next u= se case in the=C2=A0repo, so we can dive deeper into it and see how to prov= ide both central grant negotiation=C2=A0and privacy.

I've added a DID example to my implementation, wi= ll publish it soon.=C2=A0

=C2= =A0
Best regards.
/Francis
=
=C2=A0

Then I= agree with you on the audience field of the token, if left empty it simpli= fies part of the problem, although it removes a big part of the control you= may want from directed tokens. That's why I'm willing to better de= velop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Franc= is Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> a =C3=A9crit=C2=A0:
Hello= =C2=A0Denis,

what you describe in the use case seems to = be the default behavior of the protocol. Let me map it with this abstract p= rotocol flow:

+-----= ------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+---= -+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orc= hestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2= =A0| Resource Controller |
| is U= NIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is= UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2= =A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2= =A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+--------------= -------+
=C2=A0 |(1) RegisterStudent=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |--= -------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIn= tent(RecordType,StudentId,
=C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest[RecordType,Stude= ntId]
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----= ---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-------------------= -------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----------= ---->|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,Orchest= ratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------------------------|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(R= ecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 += =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +

we assume the authz request sent by= "Client" to "AS" describes the protected resource with= out referring=C2=A0to the authz server. An AS can issue the authz to releas= e the graduation record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,Stude= ntId,OrchestratorId]), without any reference to the target university.=C2= =A0

What matters for this authz object is:
<= font face=3D"monospace">- StudentId: a reference to the student as known to= the resource server.
- RecordTyp= e: a reference to a resource of type graduation record as understandable=C2= =A0 by the resource server.
-=C2= =A0OrchestratorId: reference to the Orchestrator. Can be used to bind authz= to Orchestrator.

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2=A0Orchestrator.<= /div>

Therefore, the AS does not need to know the RS. Keep the audience fi= eld empty.

= Same principle applies for the second use case.

What privacy problem do you see here?

Best regard= s.
/Francis
On Tue, A= ug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis


--
Francis Pouatcha
Co= -Founder and Technical Lead
adorsys GmbH & Co. KG
<= a href=3D"https://adorsys-platform.de/solutions/" target=3D"_blank">https:/= /adorsys-platform.de/solutions/
--0000000000006bf6d405acacd0d2-- From nobody Wed Aug 12 04:58:05 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 D94303A0FA5 for ; Wed, 12 Aug 2020 04:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 (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 1DnJgvR5RyDA for ; Wed, 12 Aug 2020 04:58:01 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 96FBB3A0FA0 for ; Wed, 12 Aug 2020 04:58:00 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id k20so1659693wmi.5 for ; Wed, 12 Aug 2020 04:58:00 -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=ZO3K0BXPExI6gGrjo7HW7LkdRN44KWZHjxtzeKT0pf4=; b=RwiUGBVJwGQvkBnhbRq5d19Ssj+TQGg+9bZOozrt9l3I0YgVm/RjrzlQ8xc++Yyfg8 RiXFkfNFVu135a0MwCmXsMlnXRMUzllWs7KLuR1GsBiVJI2b+A6/DJFv/Je+tC8MtIwu ps/FoA/ZFDHTh+6QE7WooUyf4qyOVyoSJBe+Q= 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=ZO3K0BXPExI6gGrjo7HW7LkdRN44KWZHjxtzeKT0pf4=; b=LKQhj6kbyC/0cXGNYsxP901anqUo5PtDDxeHHeUKZ9aZteO6IcknGomRQtnRQd5vtQ ZiZitWEE36+EvYYb/hA+KLBMDHb+0ZjpxaqYqON6WbYNBXmVyREpxn+7CpSur1vR+oQj mmjpMIH7h7UMwyhT+zl47+YPhdWPeHUNA+u3j3wG7uXbleLElbcMg1bZ75urRPbQ5Gim P+BrxaWtansv4gtW9NYerXcdb0tZNtLtfztM5tnxRi17cXdKevpBOVyNlZGtmJqxuuz7 QDlCCvwCX3PdF90tJKpupiupGMIZv97CTll3f8A8O112enryt6P8I03wl/v7+/4aQxEM jtZA== X-Gm-Message-State: AOAM532cvy4JnTQvGO1pRJ7sDrYoBUJtslkywMcglDXj7bIAnvCBp0jF +o0QTVg7h9oWzMFar7V+fw3KC8dy2tQuiYyUsRhWBQ== X-Google-Smtp-Source: ABdhPJyUZiH4bWzhuirbNVh9y63PrUEd48Qvl4yeWaeC/oGpIzeTdMB1xzwu9QumhoC/XFqqHlNvnBevSIlwKPrHAqo= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr8131059wmj.8.1597233479046; Wed, 12 Aug 2020 04:57:59 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> In-Reply-To: From: Francis Pouatcha Date: Wed, 12 Aug 2020 07:57:48 -0400 Message-ID: To: Dick Hardt Cc: Justin Richer , Denis , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000246ed705acace69a" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 11:58:03 -0000 --000000000000246ed705acace69a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 11, 2020 at 11:39 PM Dick Hardt wrote: > Thanks Francis > > (I'm assuming your second (2) should have been a (6) ) > Yes. Typo > > Am I correct that 1, 4, & 7 are human interactions, > Yes in the university use case. They might not be human interaction in other use cases. They are not part of the protocol, but help for use case mapping. > and 2, 3, 5, & 6 are part of the protocol? > Yes. > > =E1=90=A7 > > On Tue, Aug 11, 2020 at 7:14 PM Francis Pouatcha wrote: > >> Hello Dick, >> >> I will use the university registration use case as an example to >> illustrate steps (1) and (7). >> >> +-----------+ +--------------+ +-----------+ +----+ >> +---------------------+ >> | Requestor | | Orchestrator | | RS | | GS | | Resource >> Controller | >> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | is >> | >> | Staff | | Registr. App | | Server | | AS | | >> Student | >> +-----------+ +--------------+ +-----------+ +----+ >> +---------------------+ >> |(1) RegisterStudent(StudentId) | | = | >> |---------------------->| | | = | >> | |(2) RequestRecordIntent(RecordType,StudentId, >> | | OrchestratorId):AuthRequest[RecordType, >> StudentId] >> | |<-------------->| | = | >> | | | | = | >> | |(3) AuthZRequest(RecordType,StudentId >> ,OrchestratorId) >> | |--------------------------->| = | >> | | | |(4) >> ConsentRequest(RecordType, >> | | | | >> OrchestratorId):Consent >> | | | |<-------------->= | >> | |(5) AuthZ[RecordType,StudentId,OrchestratorId= ] >> | |<---------------------------| = | >> | | | | = | >> | |(2) RequestRecord(RecordType,StudentId >> ,OrchestratorId) >> | | :RecordOf[StudentId] | = | >> | |<-------------->| | = | >> |(7) Registered | | | = | >> |<----------------------| | | = | >> + + + + = + >> >> Step (1) is the initial service request "RegisterStudent" sent by >> the university staff to the University registration application. >> >> Step (7) is the response to step (1), the notification of the university >> staff that the registration was successful. >> >> Best regards >> /Francis >> >> >> On Tue, Aug 11, 2020 at 7:38 PM Dick Hardt wrote: >> >>> Hi Francis, responses inline ... >>> >>> On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha wrote= : >>> >>>> Hello Dick, >>>> >>>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt >>>> wrote: >>>> >>>>> Hi Francis >>>>> >>>>> The user is an entity, not a role in the protocol in how I am definin= g >>>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>>> >>>> "Requestor" is the role (*was* User). So the UML participant refers to >>>> the role "Requestor" >>>> >>> >>> I still don't understand what is happening in (1) and (7) >>> >>> >>>> >>>> >>>>> I also think that (2) could be an extension to GNAP, rather than part >>>>> of the core protocol. >>>>> >>>> If you make it an extension, you hide. It shall rather be an optional, >>>> integral part of the protocol. >>>> >>> >>> Most deployments today accomplish (2) by the developer reading RS >>> documentation. >>> >>> I'm in favor of showing that step in an abstract diagram. But it is not >>> clear to me what the requirements for (2), and they may vary radically >>> across use cases, so putting it in the core document seems to be gettin= g >>> ahead of ourselves. >>> >>> >>>> In some open banking designs, >>>> - the "Orchestrator/Negotiator/Client" will not know the AS to talk to >>>> unless the call (2). >>>> >>> >>> Have you put these use cases in the wiki? >>> >>> >>>> - the request (2) might result in an exemption, meaning no need for >>>> further authorization, allowing to skip (3, 4, 5) and even (6). >>>> >>> >>> Agreed. >>> >>>> =E1=90=A7 >>> >> >> >> -- >> Francis Pouatcha >> Co-Founder and Technical Lead >> adorsys GmbH & Co. KG >> https://adorsys-platform.de/solutions/ >> > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000246ed705acace69a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 11, 2020 at 11:39 PM Dick= Hardt <dick.hardt@gmail.com= > wrote:
Thanks Francis

(I'm assuming your secon= d (2) should have been a (6) )
Yes. Typo= =C2=A0

Am I correct that 1, 4, & 7 are human inte= ractions,
Yes in the university use cas= e. They might not be human interaction in other use cases. They are not par= t of the protocol, but help for use case=C2=A0mapping.=C2=A0
=C2= =A0
and 2, 3, 5, & 6 are part of the protocol?
=
Yes.=C2=A0

3D""=E1=90=A7

On Tue, Aug 11, 2020 at 7:14 PM Francis Pouatcha <fpo@adorsys.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hello Dick,

=
I will use the university registration = use case as an example to illustrate steps (1) and (7).

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+= =C2=A0+----+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 = =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= | GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0= |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 | Registr= . App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----= ------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+---= -+ =C2=A0+---------------------+
=C2=A0 |(1) RegisterStudent(StudentId)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div>=C2=A0 |---------------------->|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId= ,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0OrchestratorId):AuthRequest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--------------= >|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|-------------------= -------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----------= ---->|
=C2=A0 |=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=A0AuthZ[RecordType,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------------------------|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) R= equestRecord(RecordType,StudentId,OrchestratorId)
=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:Recor= dOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7= ) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<-----= -----------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

Step (1) is the initial service request "RegisterStudent" sent= by the=C2=A0university staff to the University registration application.

Step (7) is the response to step (1), the notification of th= e university staff that the registration was successful.
<= font face=3D"monospace">
Best= regards
/Francis

On Tue, Aug 11, 2020 at 7:38 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<= div>Hi Francis, responses inline ...=C2=A0

On Tue, Aug 11, 2020 at 3:37 PM F= rancis Pouatcha <fpo= @adorsys.de> wrote:
Hello Dick,
On Tue, = Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis
<= br>
The user is an entity, not a role in the protocol in how I am= defining roles, so steps (1) and (7) are confusing to me on what is happen= ing.
"Requestor" is the role (was= User). So the UML participant refers=C2=A0to the role "Requestor&= quot;

I still don't u= nderstand what is happening in (1) and (7)
=C2=A0


I also think that (2) could be an e= xtension to GNAP, rather than part of the core protocol.
If you make it an extension, you hide. It shall rather be an opt= ional, integral part of the protocol.
<= br>
Most deployments today accomplish (2) by the developer readin= g RS documentation.

I'm in favor of showing th= at step in an abstract diagram. But it is not clear to me what the requirem= ents for (2), and they may vary radically across use cases, so putting it i= n the core document seems to be getting ahead of ourselves.
=C2= =A0
In some open banking designs,=C2=A0
<= div>- the "Orchestrator/Negotiator/Client" will not know the AS t= o talk to unless the call (2).

Have you put these use cases in the wiki?
=C2=A0
- the request (2) might result in an exemption, meaning = no need for further authorization, allowing to skip (3, 4, 5) and even (6).=

Agreed.
3D""=E1=90=A7


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


--
Francis Pouatcha
Co-= Founder and Technical Lead
adorsys GmbH & Co. KG
https://= adorsys-platform.de/solutions/
--000000000000246ed705acace69a-- From nobody Wed Aug 12 05:12:34 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 4DD653A1243 for ; Wed, 12 Aug 2020 05:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 7XfwTIMgYi6k for ; Wed, 12 Aug 2020 05:12:29 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 A38673A1242 for ; Wed, 12 Aug 2020 05:12:29 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id s189so2297873iod.2 for ; Wed, 12 Aug 2020 05:12:29 -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=8MrOUpF3ydswX479HwbU5cckfQdDZJ75sWfJ/P0SC30=; b=WxuUI14fr+OZo1ZOzX7zhop/pXclbSXSHRIO5MZlkayaHe20gKq2jk8dGB94l7CX+i 4bl0aysZTz/MKWVgqWcNXBoNySV/Li+Dc8sQVzQpTnthBiCncnkxHfn2k33rmUVycws5 l+6cm19/V5e0kBot06p5L7dvc3+rJfvNdSZYfrgufPvuZjGewad+3yR/YcaPLIsCHkQj e4m33yKNdXt3bjs9kqgVM0RjHTD5Or+oPU4bXUYmPDZiX6Az1+HO2cguZ/IDeG42Cz03 zQw0jjyErd92EwS7xVnZweY9lWbAZNtYuAcIXSwEksI+EdHvYo9JM3+zWQAGW8QASyeu f3Cg== 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=8MrOUpF3ydswX479HwbU5cckfQdDZJ75sWfJ/P0SC30=; b=uVhDswN5BXxLpTJcDpSD3JmB+GPaJfwRppl+2BizKWgWtOtWmBDh3t8aoyu7syzxTq CEco45jFHefnbsB1ZLtdDC2PT7FdGJysAMenX7yM9EkMEgvAgq1PwXoWwNBMNBNnemgQ /SsH6McU0qf1/wAIPjrnbSuP0Pxm1L+1CS2STt0ihPyI7i4htOgSbItzUlxdnTUJQWXd MeXUTFmA47rS2EjQZVKCLx9ByOQeZgdxtBdHYx2qZhst3AI2HVBo7+3VrM7b++63d8dt iOtG6itQg/qV6HD7b+xoOdtmE5uuE63EM581kTilYvk2BdnXqXNFjVmWEQNbHtnDXsEg 6y+w== X-Gm-Message-State: AOAM533eQkf88h/ht2tLaX1ayz9FxaQmfOCp98MTO67yb8h041VtLzv7 ctBWULfx6wIyl+48OLBQ0nisPbpgbOoeSdMJAzs= X-Google-Smtp-Source: ABdhPJx4rF6XMCCgv1E+skirJipfCvuz/nYrhEBrnlP5urxt7aS0/pVHZZCmJABSxgnVPKCHSWf+EK3EjIq3Sk8bwSM= X-Received: by 2002:a05:6638:22c7:: with SMTP id j7mr30989225jat.77.1597234348928; Wed, 12 Aug 2020 05:12:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 12 Aug 2020 14:12:17 +0200 Message-ID: To: Francis Pouatcha Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000fdb4f005acad1988" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 12:12:32 -0000 --000000000000fdb4f005acad1988 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inline too :-) On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha wrote: > Hello Fabian, inline > > On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault > wrote: > >> Hi Francis, >> >> My comments are embedded into your email with FI. >> >> You're saying in a follow-up message: >> "- If you want privacy, *don't* expose RS identity to AS. >> - If you want transparency, expose RS identity to AS. >> You can't have both...." >> While that may seem a reasonable dichotomy at first sight, I believe the >> reality is actually more nuanced and depends on how we end up designing = the >> system. >> >> Cheers, >> Fabien >> >> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha wrote= : >> >>> Hello Fabian, >>> >>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> I think Denis points to the fact that, in the current situation, the A= S >>>> receives the resource request from the Client and therefore knows what >>>> tokens are asked. >>>> >>> The token request must not mention any reference of the RS. >>> >> >> FI : yes we can do that, but as Tom commented, it's not a general rule. >> And for instance in XYZ you do describe the URL of the resource. See als= o >> the use case on directed tokens, which is an interesting topic which mak= es >> sense in many scenarios. >> > Yes. But disclosing the protected resource discloses the RS. > FI : yes of course. Which is why RS hiding may be a solution. > > But as soon as you include that possibility, it's fair to think that this >> capability could be used for surveillance purposes in some cases, unless >> you found a privacy by design scheme that applies by default. >> > Yes. THen default shall be using URI of resource description and not URL > to indicate resource location. > FI : yes > > Again this doesn't mean that transparency requirements aren't important >> too, but I think there are other ways it can be achieved (for instance, = an >> inspiration is the certificate transparency project). Could be an extens= ion >> to the protocol I believe. >> > The certificate transparency deals with something else. Does not fit in > this context at all. > > FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component. > >> >>> >>>> Then it also implements the consent interface (and possibly the login >>>> too) and so it also knows who validates and what is accepted or not. >>>> >>> Decoupling this does not change the privacy context, as the AS issues >>> the Token. AS needs to add a reference to the RC in the token. SO AS ca= n >>> correlate on StudentId anyway. >>> >> >> FI : I disagree. It does change the privacy context, if as Denis >> suggested, the consent is made outside of the AS and if you don't send t= o >> the AS the information on the RS when it needs to issue the token. >> Correlation on StudentId is limited as long as it's a local identifier, >> i.e. not a public DID. >> > How local can the StudentId be? It is known to both universities and to > the AS. Without a public reference, you can not link information between > unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then > you do not need central AS anymore. > FI : see keri or peer DID for instance, as examples of local ID. Again SSI/DID/VC doesn't mean you don't need AS, those technologies can be complementary. > >> As a concrete example: a user may want to use an application to access >> rs_domain/directory1 and rs_domain/directory2 in read and write, which a= re >> managed by a RO. >> What I suggested is that the Client may (optionally) carry out its >> consent through a decoupled IS server (separated from the AS), that >> displays the UI based on the RS requirements =3D> the IS knows what >> information is used, but the IS may be chosen by the IS independently fr= om >> the AS or even run by the Client itself. >> > What do you need an AS for? Then it can sign the claim to present to RS. > FI : to be sure, what is "it"? > > >> In this case, suppose the RO only provided consent for >> rs_domain/directory1 for read. >> We now need to get back to the AS to mint the access token. >> > If AS mint access token, AS will be able to correlate. Unless start > applying intransparent complex reference mapping techniques, wich might > even open room for new attack vectors. > FI : not necessarily with respect to correlation, see above. As for mapping techniques, this is the very reason of my question to Denis. > > >> If we want the AS to not know about the RS, we either : >> - don't supply the rs_domain at all -> the JWT says that directory1 in >> read access is authorized. The downside is that we actually cannot contr= ol >> to which URL the authorization applies. In that case I agree with your >> either or statement. >> > Yes > >> - or find a way to hide it (not sure if that's practical, hence my >> questions on RS hiding). This would have the benefit of still allowing >> directed tokens -> the JWT says that rs_petname/directory1 in read acces= s >> is authorized. >> > More complexity. > FI : yes > >> Either way, the AS has not been provided any information as to where thi= s >> token will effectively be used. >> > >>> >>>> I don't think the abstract flow deals with those privacy concerns. >>>> >>> To solve the privacy problem addressed in this thread, we need to go th= e >>> (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a = VC >>> (Verifiable Credential) to the Student (in his role of RC). The Student >>> will then present this claim to UNIV-1 during his registration. In this >>> case we need no Grant negotiation and no AS. >>> >> >> FI : That may be useful but it's not enough. What you describe only work= s >> because you take a very specific use case, aka registration. This fits w= ell >> into DID/VC without requiring authorization per say. However grant >> negotiation is still required for more general settings of authorization= . >> > Please drop the next use case in the repo, so we can dive deeper into it > and see how to provide both central grant negotiation and privacy. > FI : will do. > > I've added a DID example to my implementation, will publish it soon. >> >> >>> Best regards. >>> /Francis >>> >>>> >>> >>>> >>>> Then I agree with you on the audience field of the token, if left empt= y >>>> it simplifies part of the problem, although it removes a big part of t= he >>>> control you may want from directed tokens. That's why I'm willing to b= etter >>>> develop the RS hiding idea. >>>> >>>> Fabien >>>> >>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>> >>>>> Hello Denis, >>>>> >>>>> what you describe in the use case seems to be the default behavior of >>>>> the protocol. Let me map it with this abstract protocol flow: >>>>> >>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>> +---------------------+ >>>>> | Requestor | | Orchestrator | | RS | | GS | | Resourc= e >>>>> Controller | >>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>> is | >>>>> | Staff | | Registr. App | | Server | | AS | | >>>>> Student | >>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>> +---------------------+ >>>>> |(1) RegisterStudent | | | >>>>> | >>>>> |---------------------->| | | >>>>> | >>>>> | |(2) >>>>> RequestRecordIntent(RecordType,StudentId, >>>>> | | >>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>> | |<-------------->| | >>>>> | >>>>> | | | | >>>>> | >>>>> | |(3) >>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>> | |--------------------------->| >>>>> | >>>>> | | | |(4) >>>>> ConsentRequest(RecordType, >>>>> | | | | >>>>> OrchestratorId):Consent >>>>> | | | >>>>> |<-------------->| >>>>> | >>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>> | |<---------------------------| >>>>> | >>>>> | | | | >>>>> | >>>>> | |(2) >>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>> | | :RecordOf[StudentId] | >>>>> | >>>>> | |<-------------->| | >>>>> | >>>>> |(7) Registered | | | >>>>> | >>>>> |<----------------------| | | >>>>> | >>>>> + + + + >>>>> + >>>>> >>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>> protected resource without referring to the authz server. An AS can i= ssue >>>>> the authz to release the graduation record of a student >>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any referen= ce to >>>>> the target university. >>>>> >>>>> What matters for this authz object is: >>>>> - StudentId: a reference to the student as known to the resource >>>>> server. >>>>> - RecordType: a reference to a resource of type graduation record as >>>>> understandable by the resource server. >>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>>> authz to Orchestrator. >>>>> >>>>> But: >>>>> - RS must trust AS issued token. >>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>> >>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>> field empty. >>>>> >>>>> Same principle applies for the second use case. >>>>> >>>>> What privacy problem do you see here? >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>> >>>>>> I tried my best twice to download three use cases in the Use cases >>>>>> directory, but I failed. >>>>>> >>>>>> Rather than failing a third time, here is the direct link of the >>>>>> second try: >>>>>> >>>>>> >>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use= -cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ > --000000000000fdb4f005acad1988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline too :-)

On Wed, Aug 12, 2020 at 1:5= 1 PM Francis Pouatcha <fpo@adorsys.de<= /a>> wrote:
<= div dir=3D"ltr">
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fa= bien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,= =C2=A0

My comments are embedded into your email with FI.=

You're saying in a follow-up message:=C2=A0
"- If you want privacy,=C2=A0don't=C2=A0expose RS = identity to AS.
- If you want transparency, expose RS identi= ty to AS.
You can't have both...."
While= that may seem=C2=A0a reasonable=C2=A0dichotomy=C2=A0at first sight, I beli= eve the reality is actually more nuanced and depends on how we end up desig= ning the system.=C2=A0

Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@= gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation,= the AS receives the resource request from the Client and therefore knows w= hat tokens are asked.
The token request must = not mention any reference of the RS.
FI : yes we can do that, but as Tom commented, it's not a g= eneral rule. And for instance in XYZ you do describe the URL of the resourc= e. See also the use case=C2=A0on directed tokens, which is an interesting t= opic which makes sense in many scenarios.=C2=A0=C2=A0
Yes. But disclosing the protected resource discloses the RS.= =C2=A0

FI : yes of course= . Which is why RS hiding may be a solution.=C2=A0
<= div>
But as soon as you include that possi= bility, it's fair to think that this capability could be used for surve= illance purposes in some cases, unless you found a privacy by design scheme= that applies by default.=C2=A0
Yes. THe= n default shall be using URI of resource description and not URL to indicat= e resource location.=C2=A0

FI : yes=C2=A0

Again this doesn't mean that transparency requirements aren'= t important too, but I think there are other ways it can be achieved (for i= nstance, an inspiration is the certificate transparency project). Could be = an extension to the protocol I believe.=C2=A0
The certificate transparency deals with something else. Does not fit = in this context at all.
=C2=A0
FI : It does, and has already been implemented by some projects in relatio= nship with OAuth2, as an additional component.=C2=A0

=C2=A0
Then it also implements the consent interface (and possibly the l= ogin too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy con= text, as the AS issues the Token. AS needs to add a reference to the=C2=A0R= C in the token. SO AS can correlate on StudentId anyway.
<= /blockquote>

FI : I disagree. It does change the privacy= context, if as Denis suggested, the consent is made outside of the AS and = if you don't send to the AS the information on the RS when it needs to = issue the token.
Correlation on StudentId is limited as long as i= t's a local identifier, i.e. not a public DID.=C2=A0
<= /blockquote>
How local can the StudentId be? It is known to both univer= sities and to the AS. Without a public reference, you can not link informat= ion between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help = here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples o= f local ID.=C2=A0
Again SSI/DID/VC doesn't mean you don't= need AS, those technologies can be complementary.=C2=A0
=C2=A0

As a concrete= example: a user may want to use an application to access rs_domain/directo= ry1 and rs_domain/directory2 in read and write, which are managed by a RO.= =C2=A0
What I suggested is that the Client may (optionally) carry= out its consent through a decoupled IS server (separated from the AS), tha= t displays the UI based on the RS requirements =3D> the IS knows what in= formation is used, but the IS may be chosen by the IS independently from th= e AS or even run by the Client itself.=C2=A0
=
What do you need an AS for? Then it can sign the claim to present to R= S.

FI : to be sure, what = is "it"?=C2=A0
=C2=A0
=C2= =A0
In this case, suppose the RO only provided= consent for rs_domain/directory1 for read.=C2=A0
We now need to = get back to the AS to mint the access token.=C2=A0
If AS mint access token, AS will be able to correlate. Unless st= art applying intransparent complex reference mapping techniques, wich might= even open room for new attack vectors.
=
FI : not necessarily with respect to correlation, see above.=
As for mapping techniques, this is the very reason of my questio= n to Denis.=C2=A0


If we want the AS to not know about the RS, we either= :=C2=A0
- don't supply the rs_domain at all -> the JWT sa= ys that directory1 in read access is authorized. The downside is that we ac= tually cannot control to which URL the authorization=C2=A0applies. In that = case I agree with your either or statement.=C2=A0=C2=A0
Yes=C2=A0
- or find a way to h= ide it (not sure if that's practical, hence my questions on RS hiding).= This would have the benefit of still allowing directed tokens -> the JW= T says that rs_petname/directory1 in read access is authorized.
=
More complexity.=C2=A0

FI : yes
=C2=A0
=C2=A0
Either way, the AS has not been prov= ided any information as to where this token will effectively be used.=C2=A0= =C2=A0


I don't think t= he abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thread, we need = to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to is= sue a VC (Verifiable Credential) to the Student (in his role of RC). The St= udent will then present this claim to UNIV-1 during his registration. In th= is case we need no Grant negotiation and=C2=A0no AS.

FI : That may be useful but it's not enough= . What you describe only works because you take a very specific use case, a= ka registration. This fits well into DID/VC without requiring authorization= per say. However grant negotiation=C2=A0is still required for more general= settings of authorization.=C2=A0=C2=A0
= Please drop the next use case in the=C2=A0repo, so we can dive deeper into = it and see how to provide both central grant negotiation=C2=A0and privacy.<= /div>

FI : will do.=C2=A0
=

I've added = a DID example to my implementation, will publish it soon.=C2=A0
<= br>
=C2=A0
Best regards.
/= Francis
=C2=A0

Then I agree with you on the audience field o= f the token, if left empty it simplifies part of the problem, although it r= emoves a big part of the control you may want from directed tokens. That= 9;s why I'm willing to better develop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao= =C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org= > a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,

what you d= escribe in the use case seems to be the default behavior of the protocol. L= et me map it with this abstract protocol flow:

+-----------+=C2=A0 =C2=A0 =C2=A0 +-------------= -+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
| Requ= estor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV= -1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0A= S |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ = =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) RegisterStudent= =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0Orchestra= torId):AuthRequest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(RecordTyp= e,StudentId,OrchestratorId)
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|--------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorI= d):Consent
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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= =A0AuthZ[RecordType,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----= -----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,StudentId,OrchestratorId)=
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0:RecordOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7= ) Registered=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<-----= -----------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

we assume the authz request sent by "Client" to "AS"= describes the protected resource without referring=C2=A0to the authz serve= r. An AS can issue the authz to release the graduation record=C2=A0 of a st= udent ((5)=C2=A0AuthZ[RecordType,StudentId,OrchestratorId]), without any re= ference to the target university.=C2=A0

What matters for this= authz object is:
- StudentId: a = reference to the student as known to the resource server.
= - RecordType: a reference to a resource of type gr= aduation record as understandable=C2=A0 by the resource server.
-=C2=A0OrchestratorId: reference to the Orch= estrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS= , AS and=C2=A0Orchestrator.

<= /font>
Therefore, the AS does not need t= o know the RS. Keep the audience field empty.

Same principl= e applies for the second use case.

What privacy problem do yo= u see here?

Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <deni= s.ietf@free.fr> wrote:
=20 =20 =20

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis


--
Francis Pouatcha
Co-Founder and Technical Lea= d
adorsys GmbH & Co. KG
--000000000000fdb4f005acad1988-- From nobody Wed Aug 12 06:24:06 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 44DDE3A1242 for ; Wed, 12 Aug 2020 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 5jC8SdfhNJGP for ; Wed, 12 Aug 2020 06:24:02 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978A23A102E for ; Wed, 12 Aug 2020 06:24:01 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d31 with ME id EdPy230092bcEcA03dPyeW; Wed, 12 Aug 2020 15:23:59 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 12 Aug 2020 15:23:59 +0200 X-ME-IP: 90.79.51.120 To: Fabien Imbault , Francis Pouatcha Cc: GNAP Mailing List References: From: Denis Message-ID: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> Date: Wed, 12 Aug 2020 15:23:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7B1436C7710BCA2AA2F863ED" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 13:24:05 -0000 This is a multi-part message in MIME format. --------------7B1436C7710BCA2AA2F863ED Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit With so many messages in the last 24 hours, I can't respond to all of them at once. I picked the last one first. > Inline too :-) > > On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha > wrote: > > Hello Fabian, inline > > On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault > > wrote: > > Hi Francis, > > My comments are embedded into your email with FI. > > You're saying in a follow-up message: > "- If you want privacy, *don't* expose RS identity to AS. > - If you want transparency, expose RS identity to AS. > You can't have both...." > While that may seem a reasonable dichotomy at first sight, I > believe the reality is actually more nuanced and depends on > how we end up designing the system. > [Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS. This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS. That random number will change for every access token. In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token with an unsigned field external to the access token. This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token. It should have two parts : a signed part and an unsigned part. > > Cheers, > Fabien > > On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha > > wrote: > > Hello Fabian, > > On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault > > wrote: > > Hi Francis, > > I think Denis points to the fact that, in the current > situation, the AS receives the resource request from > the Client and therefore knows what tokens are asked. > > The token request must not mention any reference of the RS. > > > FI : yes we can do that, but as Tom commented, it's not a > general rule. And for instance in XYZ you do describe the URL > of the resource. See also the use case on directed tokens, > which is an interesting topic which makes sense in many > scenarios. > > Yes. But disclosing the protected resource discloses the RS. > > > FI : yes of course. Which is why RS hiding may be a solution. > > > But as soon as you include that possibility, it's fair to > think that this capability could be used for surveillance > purposes in some cases, unless you found a privacy by design > scheme that applies by default. > > Yes. THen default shall be using URI of resource description and > not URL to indicate resource location. > > > FI : yes > > > Again this doesn't mean that transparency requirements aren't > important too, but I think there are other ways it can be > achieved (for instance, an inspiration is the certificate > transparency project). Could be an extension to the protocol I > believe. > > The certificate transparency deals with something else. Does not > fit in this context at all. > > FI : It does, and has already been implemented by some projects in > relationship with OAuth2, as an additional component. > > > Then it also implements the consent interface (and > possibly the login too) and so it also knows who > validates and what is accepted or not. > > Decoupling this does not change the privacy context, as > the AS issues the Token. AS needs to add a reference to > the RC in the token. SO AS can correlate on StudentId anyway. > > > FI : I disagree. It does change the privacy context, if as > Denis suggested, the consent is made outside of the AS and if > you don't send to the AS the information on the RS when it > needs to issue the token. > Correlation on StudentId is limited as long as it's a local > identifier, i.e. not a public DID. > > How local can the StudentId be? It is known to both universities > and to the AS. Without a public reference, you can not link > information between unrelated entities (AS, UNIV-0 and UNIV-1). > Using VCs can help here. Then you do not need central AS anymore. > > > FI : see keri or peer DID for instance, as examples of local ID. > Again SSI/DID/VC doesn't mean you don't need AS, those technologies > can be complementary. > > > As a concrete example: a user may want to use an application > to access rs_domain/directory1 and rs_domain/directory2 in > read and write, which are managed by a RO. > What I suggested is that the Client may (optionally) carry out > its consent through a decoupled IS server (separated from the > AS), that displays the UI based on the RS requirements => the > IS knows what information is used, but the IS may be chosen by > the IS independently from the AS or even run by the Client > itself. > > What do you need an AS for? Then it can sign the claim to present > to RS. > > > FI : to be sure, what is "it"? > > In this case, suppose the RO only provided consent for > rs_domain/directory1 for read. > We now need to get back to the AS to mint the access token. > > If AS mint access token, AS will be able to correlate. Unless > start applying intransparent complex reference mapping techniques, > wich might even open room for new attack vectors. > > > FI : not necessarily with respect to correlation, see above. > As for mapping techniques, this is the very reason of my question to > Denis. > > > > If we want the AS to not know about the RS, we either : > - don't supply the rs_domain at all -> the JWT says that > directory1 in read access is authorized. The downside is that > we actually cannot control to which URL the > authorization applies. In that case I agree with your either > or statement. > > Yes > > - or find a way to hide it (not sure if that's practical, > hence my questions on RS hiding). This would have the benefit > of still allowing directed tokens -> the JWT says that > rs_petname/directory1 in read access is authorized. > > More complexity. > > > FI : yes [Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token. BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and a Service Name (SN) identifier to which the RS belongs. Two targetting fields should hence be possible: a RS identifier and a SN identifier. This is also a difference with an OAuth 2.0 access token. > Either way, the AS has not been provided any information as to > where this token will effectively be used. > > > > I don't think the abstract flow deals with those > privacy concerns. > > To solve the privacy problem addressed in this thread, we > need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role > of RS) will have to issue a VC (Verifiable Credential) to > the Student (in his role of RC). The Student will then > present this claim to UNIV-1 during his registration. In > this case we need no Grant negotiation and no AS. > [Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example. > > FI : That may be useful but it's not enough. What you describe > only works because you take a very specific use case, aka > registration. This fits well into DID/VC without requiring > authorization per say. However grant negotiation is still > required for more general settings of authorization. > > Please drop the next use case in the repo, so we can dive deeper > into it and see how to provide both central grant negotiation and > privacy. > > > FI : will do. > > > I've added a DID example to my implementation, will publish it > soon. > > Best regards. > /Francis > > > Then I agree with you on the audience field of the > token, if left empty it simplifies part of the > problem, although it removes a big part of the control > you may want from directed tokens. That's why I'm > willing to better develop the RS hiding idea. > > Fabien > > Le mar. 11 août 2020 à 05:58, Francis Pouatcha > > a écrit : > > Hello Denis, > > what you describe in the use case seems to be the > default behavior of the protocol. Let me map it > with this abstract protocol flow: > [Denis] The redesign below has no relationship with my use case. A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared. A User is not a role, but an entity. BTW, I can't understand the role of an "Orchestrator" (which is left undefined). > > +-----------+     +--------------+  +-----------+ >  +----+  +---------------------+ > | Requestor |      | Orchestrator |  | RS        | >  | GS |  | Resource Controller | > | is UNIV-1 |      |  is UNIV-1  |  | is UNIV-0 |  > | or |  |        is          | > |  Staff   |      | Registr. App |  | Server    |  > | AS |  |    Student       | > +-----------+ +--------------+  +-----------+ >  +----+  +---------------------+ >   |(1) RegisterStudent    |             |          >  |           | > |---------------------->|               |          >  |             | >   |                       |(2) > RequestRecordIntent(RecordType,StudentId, >   |                    | >  OrchestratorId):AuthRequest[RecordType,StudentId] >   |  |<-------------->|      |                | >   |                       |             |          >  |           | >   |                       |(3) > AuthZRequest(RecordType,StudentId,OrchestratorId) >   |  |--------------------------->|               | >   |                       |             |          >  |(4) ConsentRequest(RecordType, >   |                    |       |           | >  OrchestratorId):Consent >   |                    |       |  |<-------------->| >   |  |(5) AuthZ[RecordType,StudentId,OrchestratorId] >   |  |<---------------------------|               | >   |                       |             |          >  |           | >   |                      |(2) > RequestRecord(RecordType,StudentId,OrchestratorId) >   |                      |  :RecordOf[StudentId]  >  |             | >   |  |<-------------->|      |                | >   |(7) Registered         |             |          >  |           | > |<----------------------|               |          >  |             | >   +                       +             +          >  +           + > > we assume the authz request sent by "Client" to > "AS" describes the protected resource without > referring to the authz server. An AS can issue the > authz to release the graduation record of a > student > ((5) AuthZ[RecordType,StudentId,OrchestratorId]), > without any reference to the target university. > > What matters for this authz object is: > - StudentId: a reference to the student as known > to the resource server. > - RecordType: a reference to a resource of type > graduation record as understandable  by the > resource server. > - OrchestratorId: reference to the Orchestrator. > Can be used to bind authz to Orchestrator. > > But: > - RS must trust AS issued token. > - StudentId must be known to RS, AS and Orchestrator. > > Therefore, the AS does not need to know the RS. > Keep the audience field empty. > > Same principle applies for the second use case. > > What privacy problem do you see here? > [Denis] The User, a physical person which initiates the exchanges has disappeared. No more user, no more privacy issues ? :-) Denis > > Best regards. > /Francis > > On Tue, Aug 4, 2020 at 5:08 AM Denis > > > wrote: > > I tried my best twice to download three use > cases in the Use cases directory, but I failed. > > Rather than failing a third time, here is the > direct link of the second try: > > https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) > > Denis > > > -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ > --------------7B1436C7710BCA2AA2F863ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
With so many messages in the last 24 hours, I can't respond to all of them at once.
I picked the last one first.

Inline too :-)

On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis, 

My comments are embedded into your email with FI.

You're saying in a follow-up message: 
"- If you want privacy, don't expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem a reasonable dichotomy at first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access token.

In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token.

This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case on directed tokens, which is an interesting topic which makes sense in many scenarios.  
Yes. But disclosing the protected resource discloses the RS. 

FI : yes of course. Which is why RS hiding may be a solution. 

But as soon as you include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default. 
Yes. THen default shall be using URI of resource description and not URL to indicate resource location. 

FI : yes 

Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe. 
The certificate transparency deals with something else. Does not fit in this context at all.
 
FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component. 

 
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the RC in the token. SO AS can correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID. 
How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples of local ID. 
Again SSI/DID/VC doesn't mean you don't need AS, those technologies can be complementary. 
 

As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO. 
What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements => the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself. 
What do you need an AS for? Then it can sign the claim to present to RS.

FI : to be sure, what is "it"? 
 
 
In this case, suppose the RO only provided consent for rs_domain/directory1 for read. 
We now need to get back to the AS to mint the access token. 
If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis. 


If we want the AS to not know about the RS, we either : 
- don't supply the rs_domain at all -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization applies. In that case I agree with your either or statement.  
Yes 
- or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity. 

FI : yes

[Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference with an OAuth 2.0 access token.

Either way, the AS has not been provided any information as to where this token will effectively be used.  


I don't think the abstract flow deals with those privacy concerns. 
To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and no AS.

[Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation is still required for more general settings of authorization.  
Please drop the next use case in the repo, so we can dive deeper into it and see how to provide both central grant negotiation and privacy.

FI : will do. 

I've added a DID example to my implementation, will publish it soon. 

 
Best regards.
/Francis
 

Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea. 

Fabien 

Le mar. 11 août 2020 à 05:58, Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org> a écrit :
Hello Denis,

what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.

BTW, I can't understand the role of an "Orchestrator" (which is left undefined).


+-----------+      +--------------+  +-----------+  +----+  +---------------------+
| Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource Controller |
| is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is          |
|   Staff   |      | Registr. App |  | Server    |  | AS |  |       Student       |
+-----------+      +--------------+  +-----------+  +----+  +---------------------+
  |(1) RegisterStudent    |                |           |                |
  |---------------------->|                |           |                |
  |                       |(2) RequestRecordIntent(RecordType,StudentId,
  |                       |     OrchestratorId):AuthRequest[RecordType,StudentId]
  |                       |<-------------->|           |                |
  |                       |                |           |                |
  |                       |(3) AuthZRequest(RecordType,StudentId,OrchestratorId)
  |                       |--------------------------->|                |
  |                       |                |           |(4) ConsentRequest(RecordType,
  |                       |                |           |     OrchestratorId):Consent
  |                       |                |           |<-------------->|
  |                       |(5) AuthZ[RecordType,StudentId,OrchestratorId]
  |                       |<---------------------------|                |
  |                       |                |           |                |
  |                       |(2) RequestRecord(RecordType,StudentId,OrchestratorId)
  |                       |     :RecordOf[StudentId]   |                |
  |                       |<-------------->|           |                |
  |(7) Registered         |                |           |                |
  |<----------------------|                |           |                |
  +                       +                +           +                +

we assume the authz request sent by "Client" to "AS" describes the protected resource without referring to the authz server. An AS can issue the authz to release the graduation record  of a student ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to the target university. 

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable  by the resource server.
- OrchestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
- StudentId must be known to RS, AS and Orchestrator.

Therefore, the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.

What privacy problem do you see here?

[Denis] The User, a physical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? :-)

Denis


Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis


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


--------------7B1436C7710BCA2AA2F863ED-- From nobody Wed Aug 12 07:13:23 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 EC4093A12B6 for ; Wed, 12 Aug 2020 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 z4_3b0064KS5 for ; Wed, 12 Aug 2020 07:13:18 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 DDC793A12A9 for ; Wed, 12 Aug 2020 07:13:17 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id q14so1736694ilj.8 for ; Wed, 12 Aug 2020 07:13:17 -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=LRS/gALRRnZWkBRM3J92Fus8Ze1zW2WBTIwIxFQ83AI=; b=jYTFSHMOPpUGS7H8WQ7+uEEY1M0Q6M/AzHh7DnXDSE4lhAFeSZBznpeQMrO4CONhaC EQH9jzMdok8WPeEGYLwncd6plpdOKWIXIYJa4XIgiP0A0Xtd6/0zWTnuBU9DfPzS7qtI NqVjfh0kBw63qE7LsB/A6EprsY+DGjPw5KcFeJTMTixyFadVC+3AEinhaUQC7kpSREOi IShLOAPe4h/nqef/VAYX5HAKbbZ4wu3J3QWz/cK3xdbbH5/nfdl7/c+wjXKdslwiwKdp ZpCuPufeDfJEPC/7/YufoZxzEf/hb5GLFB0jYffNl0LkHgR/RSsUlOsp8yBltJJEKM14 R+bQ== 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=LRS/gALRRnZWkBRM3J92Fus8Ze1zW2WBTIwIxFQ83AI=; b=omzLeiII1LkLu2XCyV5jYypSa/UK6vJmuzEX3c3rJ10hB+gITc/lFgGa6xYkw34Dwi A1H88Pj3uCn3kt/yJHga7PcIC6oCA/+/GJ9OaKpKXwxzdXcK3qgfiwD+qIABkU4LM8B5 ygC8OGN2CR1CrFFXiMIMzVFs4pVQOsFroxL1EfneQkuo5Yu8NDbBsrIvELD5IffbePPl I4EdAkoYWh7zum2k31/cqRFuXo7tSmqe2WfTxfK96V68gpbQL10k79NApWTkRJyD3aRE fUjuowkNIRUTsDFODDkrYJbQ3bo/rzGgNd8BTv5w42/zGO6+9CLYqZyBPLk6dKjJN6EK 4dGw== X-Gm-Message-State: AOAM533hVI1rSnQpyszvKTnAot0vizCRuJfdRb63l4xbwP8IDlrJqsjA fY2Qrq8mXxXZKZx51RSijKeALLUL6UwBrWu+Hm/HYEqvM0Y= X-Google-Smtp-Source: ABdhPJxPfQTpAaDHPeHe0xz4jxbCIEAqZmsn/CL8REa1+T5lpYUTSDeu8Cm11MimjIydz0nnkkpwYiUBFD2N0L3qfDo= X-Received: by 2002:a92:bb0e:: with SMTP id w14mr10713927ili.68.1597241597006; Wed, 12 Aug 2020 07:13:17 -0700 (PDT) MIME-Version: 1.0 References: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> In-Reply-To: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> From: Fabien Imbault Date: Wed, 12 Aug 2020 16:13:05 +0200 Message-ID: To: Denis Cc: Francis Pouatcha , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000002a24205acaeca62" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 14:13:21 -0000 --00000000000002a24205acaeca62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Denis. A few questions to clarify: - "the field included into the access token will look like a random number to the RS." - you mean AS? - "It should have two parts : a signed part and an unsigned part." - Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with short expiry) between the temporary_id and the url, on the RS side? Then the algorithm would be : 1. Client contacts the RS, which sends a resource description (temporary_id= ) 2. The flow continues and a token is generated, using the temporary_id 3. Client makes the call to the RS, using the token. The RS verifies the signature + it also verifies that the mapping is the one expected. BTW, it makes the RS decide the maximum token expiry. The issue is that it requires more work on the RS side, compared to a stateless JWT. Is that correct? Fabien On Wed, Aug 12, 2020 at 3:24 PM Denis wrote: > With so many messages in the last 24 hours, I can't respond to all of the= m > at once. > I picked the last one first. > > Inline too :-) > > On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha wrote: > >> Hello Fabian, inline >> >> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault >> wrote: >> >>> Hi Francis, >>> >>> My comments are embedded into your email with FI. >>> >>> You're saying in a follow-up message: >>> "- If you want privacy, *don't* expose RS identity to AS. >>> - If you want transparency, expose RS identity to AS. >>> You can't have both...." >>> While that may seem a reasonable dichotomy at first sight, I believe th= e >>> reality is actually more nuanced and depends on how we end up designing= the >>> system. >>> >> [Denis] This is in fact more nuanced. It is possible to prevent the AS t= o > know who the RS is by hiding the true identifier of the RS to the AS. > > This means that for security reasons the access token is still targeted > but that the field included into the access token will look like a random > number to the RS. > That random number will change for every access token. > > In order for the RS to make sure that the access token is indeed intended > for itself, it will need to combine the field included into the access > token > with an unsigned field external to the access token. > > This would have a major consequence for the structure of a GNAP access > token that will be rather different from an OAuth 2.0 access token. > It should have two parts : a signed part and an unsigned part. > > >>> Cheers, >>> Fabien >>> >>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha >>> wrote: >>> >>>> Hello Fabian, >>>> >>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi Francis, >>>>> >>>>> I think Denis points to the fact that, in the current situation, the >>>>> AS receives the resource request from the Client and therefore knows = what >>>>> tokens are asked. >>>>> >>>> The token request must not mention any reference of the RS. >>>> >>> >>> FI : yes we can do that, but as Tom commented, it's not a general rule. >>> And for instance in XYZ you do describe the URL of the resource. See al= so >>> the use case on directed tokens, which is an interesting topic which ma= kes >>> sense in many scenarios. >>> >> Yes. But disclosing the protected resource discloses the RS. >> > > FI : yes of course. Which is why RS hiding may be a solution. > >> >> But as soon as you include that possibility, it's fair to think that thi= s >>> capability could be used for surveillance purposes in some cases, unles= s >>> you found a privacy by design scheme that applies by default. >>> >> Yes. THen default shall be using URI of resource description and not URL >> to indicate resource location. >> > > FI : yes > >> >> Again this doesn't mean that transparency requirements aren't important >>> too, but I think there are other ways it can be achieved (for instance,= an >>> inspiration is the certificate transparency project). Could be an exten= sion >>> to the protocol I believe. >>> >> The certificate transparency deals with something else. Does not fit in >> this context at all. >> >> > FI : It does, and has already been implemented by some projects in > relationship with OAuth2, as an additional component. > >> >>> >>>> >>>>> Then it also implements the consent interface (and possibly the login >>>>> too) and so it also knows who validates and what is accepted or not. >>>>> >>>> Decoupling this does not change the privacy context, as the AS issues >>>> the Token. AS needs to add a reference to the RC in the token. SO AS c= an >>>> correlate on StudentId anyway. >>>> >>> >>> FI : I disagree. It does change the privacy context, if as Denis >>> suggested, the consent is made outside of the AS and if you don't send = to >>> the AS the information on the RS when it needs to issue the token. >>> Correlation on StudentId is limited as long as it's a local identifier, >>> i.e. not a public DID. >>> >> How local can the StudentId be? It is known to both universities and to >> the AS. Without a public reference, you can not link information between >> unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. The= n >> you do not need central AS anymore. >> > > FI : see keri or peer DID for instance, as examples of local ID. > Again SSI/DID/VC doesn't mean you don't need AS, those technologies can b= e > complementary. > > >> >>> As a concrete example: a user may want to use an application to access >>> rs_domain/directory1 and rs_domain/directory2 in read and write, which = are >>> managed by a RO. >>> What I suggested is that the Client may (optionally) carry out its >>> consent through a decoupled IS server (separated from the AS), that >>> displays the UI based on the RS requirements =3D> the IS knows what >>> information is used, but the IS may be chosen by the IS independently f= rom >>> the AS or even run by the Client itself. >>> >> What do you need an AS for? Then it can sign the claim to present to RS. >> > > FI : to be sure, what is "it"? > > >> >> >>> In this case, suppose the RO only provided consent for >>> rs_domain/directory1 for read. >>> We now need to get back to the AS to mint the access token. >>> >> If AS mint access token, AS will be able to correlate. Unless start >> applying intransparent complex reference mapping techniques, wich might >> even open room for new attack vectors. >> > > FI : not necessarily with respect to correlation, see above. > As for mapping techniques, this is the very reason of my question to > Denis. > >> >> >>> If we want the AS to not know about the RS, we either : >>> - don't supply the rs_domain at all -> the JWT says that directory1 in >>> read access is authorized. The downside is that we actually cannot cont= rol >>> to which URL the authorization applies. In that case I agree with your >>> either or statement. >>> >> Yes >> >>> - or find a way to hide it (not sure if that's practical, hence my >>> questions on RS hiding). This would have the benefit of still allowing >>> directed tokens -> the JWT says that rs_petname/directory1 in read acce= ss >>> is authorized. >>> >> More complexity. >> > > FI : yes > > [Denis] As indicated at the top of this email, it is possible to always > hide the identifier of the RS while still targetting every access token. > > BTW, I have expanded the notion of targetting by allowing to place into a > target field of an access token either or both a RS identifier and > a Service Name (SN) identifier to which the RS belongs. > > Two targetting fields should hence be possible: a RS identifier and a SN > identifier. > > This is also a difference with an OAuth 2.0 access token. > > Either way, the AS has not been provided any information as to where this >>> token will effectively be used. >>> >> >>>> >>>>> I don't think the abstract flow deals with those privacy concerns. >>>>> >>>> To solve the privacy problem addressed in this thread, we need to go >>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to iss= ue a >>>> VC (Verifiable Credential) to the Student (in his role of RC). The Stu= dent >>>> will then present this claim to UNIV-1 during his registration. In thi= s >>>> case we need no Grant negotiation and no AS. >>>> >>> [Denis] This is a complete redesign of my example and hence this > redesign has no relationship with my example. > > >>> FI : That may be useful but it's not enough. What you describe only >>> works because you take a very specific use case, aka registration. This >>> fits well into DID/VC without requiring authorization per say. However >>> grant negotiation is still required for more general settings of >>> authorization. >>> >> Please drop the next use case in the repo, so we can dive deeper into it >> and see how to provide both central grant negotiation and privacy. >> > > FI : will do. > >> >> I've added a DID example to my implementation, will publish it soon. >>> >>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>>> >>>>> Then I agree with you on the audience field of the token, if left >>>>> empty it simplifies part of the problem, although it removes a big pa= rt of >>>>> the control you may want from directed tokens. That's why I'm willing= to >>>>> better develop the RS hiding idea. >>>>> >>>>> Fabien >>>>> >>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>> >>>>>> Hello Denis, >>>>>> >>>>>> what you describe in the use case seems to be the default behavior o= f >>>>>> the protocol. Let me map it with this abstract protocol flow: >>>>>> >>>>> [Denis] The redesign below has no relationship with my use case. > > A key element of my design is the User, i.e. a physical person which > initiates the exchanges. In the example below the User has disappeared. > > A User is not a role, but an entity. > > BTW, I can't understand the role of an "Orchestrator" (which is left > undefined). > > >>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>> +---------------------+ >>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>> Resource Controller | >>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>> is | >>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>> Student | >>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>> +---------------------+ >>>>>> |(1) RegisterStudent | | | >>>>>> | >>>>>> |---------------------->| | | >>>>>> | >>>>>> | |(2) >>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>> | | >>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>> | |<-------------->| | >>>>>> | >>>>>> | | | | >>>>>> | >>>>>> | |(3) >>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>> | |--------------------------->| >>>>>> | >>>>>> | | | |(4) >>>>>> ConsentRequest(RecordType, >>>>>> | | | | >>>>>> OrchestratorId):Consent >>>>>> | | | >>>>>> |<-------------->| >>>>>> | >>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>> | |<---------------------------| >>>>>> | >>>>>> | | | | >>>>>> | >>>>>> | |(2) >>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>> | | :RecordOf[StudentId] | >>>>>> | >>>>>> | |<-------------->| | >>>>>> | >>>>>> |(7) Registered | | | >>>>>> | >>>>>> |<----------------------| | | >>>>>> | >>>>>> + + + + >>>>>> + >>>>>> >>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>> protected resource without referring to the authz server. An AS can = issue >>>>>> the authz to release the graduation record of a student >>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refere= nce to >>>>>> the target university. >>>>>> >>>>>> What matters for this authz object is: >>>>>> - StudentId: a reference to the student as known to the resource >>>>>> server. >>>>>> - RecordType: a reference to a resource of type graduation record as >>>>>> understandable by the resource server. >>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind >>>>>> authz to Orchestrator. >>>>>> >>>>>> But: >>>>>> - RS must trust AS issued token. >>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>> >>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>> field empty. >>>>>> >>>>>> Same principle applies for the second use case. >>>>>> >>>>>> What privacy problem do you see here? >>>>>> >>>>> [Denis] The User, a physical person which initiates the exchanges has > disappeared. > No more user, no more privacy issues ? :-) > > Denis > > >>>>>> Best regards. >>>>>> /Francis >>>>>> >>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>> >>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>> directory, but I failed. >>>>>>> >>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>> second try: >>>>>>> >>>>>>> >>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-us= e-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> -- >> 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 > --00000000000002a24205acaeca62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Denis.

A few qu= estions to clarify:=C2=A0
- "the field included into the access token will look like a random number to the RS." - = you mean AS?
- "It should have two parts : a signed part= and an unsigned part." - Something like an authenticated cipher (e.g.= AES-GCM) + a KV mapping (with short expiry) between the temporary_id and t= he url, on the RS side?

Then the algorithm would b= e :
1. Client contacts the RS, which sends a resource description= (temporary_id)
2. The flow continues and a token is generated, u= sing the temporary_id
3. Client makes the call to the RS, using t= he token. The RS verifies the signature=C2=A0+ it also verifies that the ma= pping is the one expected.=C2=A0=C2=A0

BTW, it mak= es the RS decide the maximum token expiry.
The issue is that it r= equires more work on the RS side, compared to a stateless JWT.=C2=A0 =C2=A0=

Is that correct?

Fab= ien


On Wed, Aug 12, 2020 at 3:24 PM Denis <denis.ietf@free.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> =20 =20 =20
With so many messages in the last 24 hours, I can't respond to all of them at once.
I picked the last one first.

=20
Inline too :-)

On Wed, Aug 12, 2020 at 1:5= 1 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0

My comments are embedded into your email with FI.

You're saying in a follow-up message:=C2=A0<= /div>
"- If you want privacy,=C2=A0don't=C2=A0expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem=C2=A0a reasonable=C2=A0dicho= tomy=C2=A0at first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access token.

In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token.

This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case=C2=A0on directed tokens, which is an interesting topic which makes sense in many scenarios.=C2=A0=C2=A0
Yes. But disclosing the protected resource discloses the RS.=C2=A0

FI : yes of course. Which is why RS hiding may be a solution.=C2=A0

But as soon as you include that possibility, it's fair to think that this capability could b= e used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default.=C2=A0
Yes. THen default shall be using URI of resource description and not URL to indicate resource location.=C2=A0

FI : yes=C2=A0

Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe.=C2=A0
The certificate transparency deals with something else. Does not fit in this context at all.
=C2=A0
FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component.=C2=A0

=C2=A0
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the=C2=A0RC in the token. SO AS can correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID.=C2=A0
How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples of local ID.=C2=A0
Again SSI/DID/VC doesn't mean you don't need AS, tho= se technologies can be complementary.=C2=A0
=C2=A0

As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO.=C2=A0
What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements =3D> the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself.=C2=A0
What do you need an AS for? Then it can sign the claim to present to RS.

FI : to be sure, what is "it"?=C2=A0
=C2=A0
=C2=A0
In this case, suppose the RO only provided consent for rs_domain/directory1 for read.=C2=A0
We now need to get back to the AS to mint the access token.=C2=A0
If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis.=C2=A0


If we want the AS to not know about the RS, we either :=C2=A0
- don't supply the rs_domain at all -> th= e JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization=C2=A0applies. In that case I agree wi= th your either or statement.=C2=A0=C2=A0
Yes=C2=A0
- or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity.=C2=A0

FI : yes

[Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference with an OAuth 2.0 access token.

Either way, the AS has not been provided any information as to where this token will effectively be used.=C2=A0=C2=A0


I don't think the abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and=C2=A0no AS.

[Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation=C2=A0is still required for more general settings of authorization.=C2=A0=C2=A0
Please drop the next use case in the=C2=A0repo, so we can dive deeper into it and see how to provide both central grant negotiation=C2=A0and privacy.

FI : will do.=C2=A0

I've added a DID example to my implementation, will publish it soon.=C2=A0

=C2=A0
Best regards.
/Francis
=C2=A0

Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Fran= cis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org&= gt; a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,

what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.<= /p>

BTW, I can't understand the role of an "Orchestrator" (which is left undefined).


+------= -----+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0= | Orchestrator | =C2=A0|=C2=A0RS=C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Con= troller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |= =C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |= =C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0= =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) RegisterStudent=C2=A0= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId,
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest= [RecordType,StudentId]
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------------------= ->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,=
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->| =C2=A0 |=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=A0AuthZ[RecordType,= StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----------------------= -----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,Studen= tId,OrchestratorId)
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +

we assume the authz request sent by "Client" to "AS"= ; describes the protected resource without referring=C2=A0to the authz server. An AS can issue the authz to release the graduation record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,StudentI= d,OrchestratorId]), without any reference to the target university.=C2=A0

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable=C2=A0 by t= he resource server.
-=C2=A0Or= chestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.<= /div>
-=C2=A0St= udentId must be known to RS, AS and=C2=A0Orchestrator.

Therefore= , the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.

What privacy problem do you see here?

[Denis] The User, a physical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? :-)

Denis


Best regards.
/Francis<= /font>

O= n Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-gnap/general/wiki/Thr= ee-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Desig= n%22-(PbD)

Denis


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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000002a24205acaeca62-- From nobody Wed Aug 12 07:14:19 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 F35123A12B6 for ; Wed, 12 Aug 2020 07:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 X6GAkYY5YGYo for ; Wed, 12 Aug 2020 07:14:16 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6118E3A12A9 for ; Wed, 12 Aug 2020 07:14:15 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d31 with ME id EeED230012bcEcA03eEDcu; Wed, 12 Aug 2020 16:14:13 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 12 Aug 2020 16:14:13 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt , Francis Pouatcha Cc: Justin Richer , Benjamin Kaduk , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> From: Denis Message-ID: <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> Date: Wed, 12 Aug 2020 16:14:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------55A4BFE1C6E2ADCF0DBEA293" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 14:14:18 -0000 This is a multi-part message in MIME format. --------------55A4BFE1C6E2ADCF0DBEA293 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > Hi Francis, responses inline ... > > On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha > wrote: > > Hello Dick, > > On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt > wrote: > > Hi Francis > > The user is an entity, not a role in the protocol in how I am > defining roles, so steps (1) and (7) are confusing to me on > what is happening. > > "Requestor" is the role (*was* User). So the UML participant > refers to the role "Requestor" > > > I still don't understand what is happening in (1) and (7) > > > > I also think that (2) could be an extension to GNAP, rather > than part of the core protocol. > > If you make it an extension, you hide. It shall rather be an > optional, integral part of the protocol. > > > Most deployments today accomplish (2) by the developer reading RS > documentation. I'm in favor of showing that step in an abstract diagram. [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk. One of the goals is for any Client to access any RS without the need to read any documentation. > But it is not clear to me what the requirements for (2), and they may > vary radically across use cases, so putting it in the core document > seems to be getting ahead of ourselves. [Denis] I can only reinsist on earlier explanations given about the Client-server use cases built along "Privacy by Design" since they are fundamental. Taking into consideration both the "data minimization" principle and the "user participation" principle when a user first authenticates to a RS leads to the following: 1) When accessing a RS for the first time, the user should be informed of the authentication means proposed by the RS. The user should be able to use a dialog box where some choices are presented by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client. 2) When a user chooses to perform one operation on a RS, the RS should limit the data to be collected from the user to only what is strictly necessary to perform that operation. That data consists of specific types of attributes that need to be guaranteed by one or more ASs. The user should be able to use a dialog box where some ASs choices are proposed by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client. It is important to notice that the choices that will be proposed to a user may depend upon previous personal information voluntarily released by that user. This means that the choices proposed by the RS may be tailored for the user. Furthermore, the proposed choices may only be disclosed to already authenticated users. Denis > In some open banking designs, > - the "Orchestrator/Negotiator/Client" will not know the AS to > talk to unless the call (2). > > > Have you put these use cases in the wiki? > > - the request (2) might result in an exemption, meaning no need > for further authorization, allowing to skip (3, 4, 5) and even (6). > > > Agreed. > > ᐧ --------------55A4BFE1C6E2ADCF0DBEA293 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Dick,

Hi Francis, responses inline ... 

On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). So the UML participant refers to the role "Requestor"

I still don't understand what is happening in (1) and (7)
 


I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol.

Most deployments today accomplish (2) by the developer reading RS documentation. I'm in favor of showing that step in an abstract diagram.

[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk.

One of the goals is for any Client to access any RS without the need to read any documentation.

But it is not clear to me what the requirements for (2), and they may vary radically across use cases, so putting it in the core document seems to be getting ahead of ourselves.

[Denis] I can only reinsist on earlier explanations given about the Client-server use cases built along "Privacy by Design" since they are fundamental.

Taking into consideration both the "data minimization" principle and the "user participation" principle when a user first authenticates to a RS leads to the following:

1) When accessing a RS for the first time, the user should be informed of the authentication means proposed by the RS. The user should be able to use a dialog box
where some choices are presented by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client.

2) When a user chooses to perform one operation on a RS, the RS should limit the data to be collected from the user to only what is strictly necessary
to perform that operation. That data consists of specific types of attributes that need to be guaranteed by one or more ASs. The user should be able
to use a dialog box where some ASs choices are proposed by the RS. The user should be able to locally make his own choices and to indicate
his consent to its Client.

It is important to notice that the choices that will be proposed to a user may depend upon previous personal information voluntarily released by that user.
This means that the choices proposed by the RS may be tailored for the user. Furthermore, the proposed choices may only be disclosed to already authenticated users.

Denis

 
In some open banking designs, 
- the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2).

Have you put these use cases in the wiki?
 
- the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

Agreed.
ᐧ


--------------55A4BFE1C6E2ADCF0DBEA293-- From nobody Wed Aug 12 07:34:59 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 4E3C83A12D1 for ; Wed, 12 Aug 2020 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KTuY3KjEG3cw for ; Wed, 12 Aug 2020 07:34:54 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223103A12E7 for ; Wed, 12 Aug 2020 07:34:52 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d31 with ME id Eeaq230042bcEcA03eaqNS; Wed, 12 Aug 2020 16:34:51 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 12 Aug 2020 16:34:51 +0200 X-ME-IP: 90.79.51.120 To: Fabien Imbault Cc: Francis Pouatcha , GNAP Mailing List References: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> From: Denis Message-ID: Date: Wed, 12 Aug 2020 16:34:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5400C7BDA7257099DD08F360" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 14:34:57 -0000 This is a multi-part message in MIME format. --------------5400C7BDA7257099DD08F360 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi  Fabien, > Thanks Denis. > > A few questions to clarify: > - "the field included into the access token will look like a random > number to the RS." - you mean AS? Correct. This was a typo. > - "It should have two parts : a signed part and an unsigned part." - > Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping > (with short expiry) between the temporary_id and the url, on the RS side? Sorry, I am not aware of this scheme. > Then the algorithm would be : > 1. Client contacts the RS, which sends a resource description > (temporary_id) No. It is not a temporary_id. > 2. The flow continues and a token is generated, using the temporary_id. No. Knowing the true identifier of the RS, the Client picks a random_number and computes a concealed_target_identifier =  hash (random_number, RS_identifier). While requesting an access token, the Client asks the AS to include the concealed_target_identifier into the access token. While sending the access token, the Client adds the random_number into the unsigned part of the access token. While receiving the access token, the RS uses it own RS_identifier and retrieves the random_number placed into the unsigned part of the access token. It then computes a hash of (random_number, RS_identifier). If the result matches with the concealed_target_identifier placed into the signed part of the access token, then the access token is well targeted, otherwise it is ignored. > 3. Client makes the call to the RS, using the token. The RS verifies > the signature + it also verifies that the mapping is the one expected. > > BTW, it makes the RS decide the maximum token expiry. Token expiration is unrelated. > The issue is that it requires more work on the RS side, compared to a > stateless JWT. Adding two computations using a one way hash function is not a big deal. >  Is that correct? No. The mechanism is fairly different. It has already been explained once on the OAuth mailing list. Denis > > Fabien > > > On Wed, Aug 12, 2020 at 3:24 PM Denis > wrote: > > With so many messages in the last 24 hours, I can't respond to all > of them at once. > I picked the last one first. > >> Inline too :-) >> >> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha > > wrote: >> >> Hello Fabian, inline >> >> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault >> > >> wrote: >> >> Hi Francis, >> >> My comments are embedded into your email with FI. >> >> You're saying in a follow-up message: >> "- If you want privacy, *don't* expose RS identity to AS. >> - If you want transparency, expose RS identity to AS. >> You can't have both...." >> While that may seem a reasonable dichotomy at first >> sight, I believe the reality is actually more nuanced and >> depends on how we end up designing the system. >> > [Denis] This is in fact more nuanced. It is possible to prevent > the AS to know who the RS is by hiding the true identifier of the > RS to the AS. > > This means that for security reasons the access token is still > targeted but that the field included into the access token will > look like a random number to the RS. > That random number will change for every access token. > > In order for the RS to make sure that the access token is indeed > intended for itself, it will need to combine the field included > into the access token > with an unsigned field external to the access token. > > This would have a major consequence for the structure of a GNAP > access token that will be rather different from an OAuth 2.0 > access token. > It should have two parts : a signed part and an unsigned part. > >> >> Cheers, >> Fabien >> >> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha >> > wrote: >> >> Hello Fabian, >> >> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault >> > > wrote: >> >> Hi Francis, >> >> I think Denis points to the fact that, in the >> current situation, the AS receives the resource >> request from the Client and therefore knows what >> tokens are asked. >> >> The token request must not mention any reference of >> the RS. >> >> >> FI : yes we can do that, but as Tom commented, it's not a >> general rule. And for instance in XYZ you do describe the >> URL of the resource. See also the use case on directed >> tokens, which is an interesting topic which makes sense >> in many scenarios. >> >> Yes. But disclosing the protected resource discloses the RS. >> >> >> FI : yes of course. Which is why RS hiding may be a solution. >> >> >> But as soon as you include that possibility, it's fair to >> think that this capability could be used for surveillance >> purposes in some cases, unless you found a privacy by >> design scheme that applies by default. >> >> Yes. THen default shall be using URI of resource description >> and not URL to indicate resource location. >> >> >> FI : yes >> >> >> Again this doesn't mean that transparency requirements >> aren't important too, but I think there are other ways it >> can be achieved (for instance, an inspiration is the >> certificate transparency project). Could be an extension >> to the protocol I believe. >> >> The certificate transparency deals with something else. Does >> not fit in this context at all. >> >> FI : It does, and has already been implemented by some projects >> in relationship with OAuth2, as an additional component. >> >> >> Then it also implements the consent interface >> (and possibly the login too) and so it also knows >> who validates and what is accepted or not. >> >> Decoupling this does not change the privacy context, >> as the AS issues the Token. AS needs to add a >> reference to the RC in the token. SO AS can correlate >> on StudentId anyway. >> >> >> FI : I disagree. It does change the privacy context, if >> as Denis suggested, the consent is made outside of the AS >> and if you don't send to the AS the information on the RS >> when it needs to issue the token. >> Correlation on StudentId is limited as long as it's a >> local identifier, i.e. not a public DID. >> >> How local can the StudentId be? It is known to both >> universities and to the AS. Without a public reference, you >> can not link information between unrelated entities (AS, >> UNIV-0 and UNIV-1). Using VCs can help here. Then you do not >> need central AS anymore. >> >> >> FI : see keri or peer DID for instance, as examples of local ID. >> Again SSI/DID/VC doesn't mean you don't need AS, those >> technologies can be complementary. >> >> >> As a concrete example: a user may want to use an >> application to access rs_domain/directory1 and >> rs_domain/directory2 in read and write, which are managed >> by a RO. >> What I suggested is that the Client may (optionally) >> carry out its consent through a decoupled IS server >> (separated from the AS), that displays the UI based on >> the RS requirements => the IS knows what information is >> used, but the IS may be chosen by the IS independently >> from the AS or even run by the Client itself. >> >> What do you need an AS for? Then it can sign the claim to >> present to RS. >> >> >> FI : to be sure, what is "it"? >> >> In this case, suppose the RO only provided consent for >> rs_domain/directory1 for read. >> We now need to get back to the AS to mint the access token. >> >> If AS mint access token, AS will be able to correlate. Unless >> start applying intransparent complex reference mapping >> techniques, wich might even open room for new attack vectors. >> >> >> FI : not necessarily with respect to correlation, see above. >> As for mapping techniques, this is the very reason of my question >> to Denis. >> >> >> >> If we want the AS to not know about the RS, we either : >> - don't supply the rs_domain at all -> the JWT says that >> directory1 in read access is authorized. The downside is >> that we actually cannot control to which URL the >> authorization applies. In that case I agree with your >> either or statement. >> >> Yes >> >> - or find a way to hide it (not sure if that's practical, >> hence my questions on RS hiding). This would have the >> benefit of still allowing directed tokens -> the JWT says >> that rs_petname/directory1 in read access is authorized. >> >> More complexity. >> >> >> FI : yes > > [Denis] As indicated at the top of this email, it is possible to > always hide the identifier of the RS while still targetting every > access token. > > BTW, I have expanded the notion of targetting by allowing to place > into a target field of an access token either or both a RS > identifier and > a Service Name (SN) identifier to which the RS belongs. > > Two targetting fields should hence be possible: a RS identifier > and a SN identifier. > > This is also a difference with an OAuth 2.0 access token. > >> Either way, the AS has not been provided any information >> as to where this token will effectively be used. >> >> >> >> I don't think the abstract flow deals with those >> privacy concerns. >> >> To solve the privacy problem addressed in this >> thread, we need to go the (SSI/DiD/VC) way. Then >> UNIV-0 (in his role of RS) will have to issue a VC >> (Verifiable Credential) to the Student (in his role >> of RC). The Student will then present this claim to >> UNIV-1 during his registration. In this case we need >> no Grant negotiation and no AS. >> > [Denis] This is a complete redesign of my example and hence this > redesign has no relationship with my example. > >> >> FI : That may be useful but it's not enough. What you >> describe only works because you take a very specific use >> case, aka registration. This fits well into DID/VC >> without requiring authorization per say. However grant >> negotiation is still required for more general settings >> of authorization. >> >> Please drop the next use case in the repo, so we can dive >> deeper into it and see how to provide both central grant >> negotiation and privacy. >> >> >> FI : will do. >> >> >> I've added a DID example to my implementation, will >> publish it soon. >> >> Best regards. >> /Francis >> >> >> Then I agree with you on the audience field of >> the token, if left empty it simplifies part of >> the problem, although it removes a big part of >> the control you may want from directed tokens. >> That's why I'm willing to better develop the RS >> hiding idea. >> >> Fabien >> >> Le mar. 11 août 2020 à 05:58, Francis Pouatcha >> > > a écrit : >> >> Hello Denis, >> >> what you describe in the use case seems to be >> the default behavior of the protocol. Let me >> map it with this abstract protocol flow: >> > [Denis] The redesign below has no relationship with my use case. > > A key element of my design is the User, i.e. a physical person > which initiates the exchanges. In the example below the User has > disappeared. > > A User is not a role, but an entity. > > BTW, I can't understand the role of an "Orchestrator" (which is > left undefined). > >> >> +-----------+     +--------------+ >>  +-----------+  +----+  +---------------------+ >> | Requestor |      | Orchestrator |  | RS    >>     |  | GS |  | Resource Controller | >> | is UNIV-1 |      | is UNIV-1   |  | is >> UNIV-0 |  | or |  |        is          | >> |  Staff   |      | Registr. App |  | Server  >>   |  | AS | |       Student  | >> +-----------+ +--------------+  +-----------+ >>  +----+  +---------------------+ >>   |(1) RegisterStudent |                |     >>      |       | >> |---------------------->|               |     >>  |   | >>   |      |(2) >> RequestRecordIntent(RecordType,StudentId, >> |    | >>  OrchestratorId):AuthRequest[RecordType,StudentId] >> |  |<-------------->|          |       | >>   |      |   |           |           | >>   |      |(3) >> AuthZRequest(RecordType,StudentId,OrchestratorId) >> |  |--------------------------->|               | >>   |      |   |           |(4) >> ConsentRequest(RecordType, >> |    | |           |  OrchestratorId):Consent >> |    | |  |<-------------->| >>   | >>  |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>   |  |<---------------------------|           >>     | >>   |      |   |           |           | >> |      |(2) >> RequestRecord(RecordType,StudentId,OrchestratorId) >> |      |  :RecordOf[StudentId]  | | >> |  |<-------------->|          |       | >>   |(7) Registered      |   |           |     >>       | >> |<----------------------|               |     >>  |   | >>   +      +   +           +           + >> >> we assume the authz request sent by "Client" >> to "AS" describes the protected resource >> without referring to the authz server. An AS >> can issue the authz to release the graduation >> record  of a student >> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), >> without any reference to the target university. >> >> What matters for this authz object is: >> - StudentId: a reference to the student as >> known to the resource server. >> - RecordType: a reference to a resource of >> type graduation record as understandable  by >> the resource server. >> - OrchestratorId: reference to the >> Orchestrator. Can be used to bind authz to >> Orchestrator. >> >> But: >> - RS must trust AS issued token. >> - StudentId must be known to RS, AS >> and Orchestrator. >> >> Therefore, the AS does not need to know the >> RS. Keep the audience field empty. >> >> Same principle applies for the second use case. >> >> What privacy problem do you see here? >> > [Denis] The User, a physical person which initiates the exchanges > has disappeared. > No more user, no more privacy issues ? :-) > > Denis > >> >> Best regards. >> /Francis >> >> On Tue, Aug 4, 2020 at 5:08 AM Denis >> > > wrote: >> >> I tried my best twice to download three >> use cases in the Use cases directory, but >> I failed. >> >> Rather than failing a third time, here is >> the direct link of the second try: >> >> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >> >> Denis >> >> >> -- >> 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 > --------------5400C7BDA7257099DD08F360 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi  Fabien,
Thanks Denis.

A few questions to clarify: 
- "the field included into the access token will look like a random number to the RS." - you mean AS?

Correct. This was a typo.

- "It should have two parts : a signed part and an unsigned part." - Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with short expiry) between the temporary_id and the url, on the RS side?

Sorry, I am not aware of this scheme.

Then the algorithm would be :
1. Client contacts the RS, which sends a resource description (temporary_id)

No. It is not a temporary_id. 

2. The flow continues and a token is generated, using the temporary_id.

No. Knowing the true identifier of the RS, the Client picks a random_number and computes a concealed_target_identifier =  hash (random_number, RS_identifier).

While requesting an access token, the Client asks the AS to include the concealed_target_identifier into the access token.

While sending the access token, the Client adds the random_number into the unsigned part of the access token.

While receiving the access token, the RS uses it own RS_identifier and retrieves the random_number placed into the unsigned part of the access token.
It then computes a hash of (random_number, RS_identifier). If the result matches with the concealed_target_identifier placed into the signed part of
the access token, then the access token is well targeted, otherwise it is ignored.

3. Client makes the call to the RS, using the token. The RS verifies the signature + it also verifies that the mapping is the one expected.  

BTW, it makes the RS decide the maximum token expiry.

Token expiration is unrelated.

The issue is that it requires more work on the RS side, compared to a stateless JWT. 

Adding two computations using a one way hash function is not a big deal.

 Is that correct?

No. The mechanism is fairly different. It has already been explained once on the OAuth mailing list.

Denis


Fabien


On Wed, Aug 12, 2020 at 3:24 PM Denis <denis.ietf@free.fr> wrote:
With so many messages in the last 24 hours, I can't respond to all of them at once.
I picked the last one first.

Inline too :-)

On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis, 

My comments are embedded into your email with FI.

You're saying in a follow-up message: 
"- If you want privacy, don't expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem a reasonable dichotomy at first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access token.

In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token.

This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case on directed tokens, which is an interesting topic which makes sense in many scenarios.  
Yes. But disclosing the protected resource discloses the RS. 

FI : yes of course. Which is why RS hiding may be a solution. 

But as soon as you include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default. 
Yes. THen default shall be using URI of resource description and not URL to indicate resource location. 

FI : yes 

Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe. 
The certificate transparency deals with something else. Does not fit in this context at all.
 
FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component. 

 
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the RC in the token. SO AS can correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID. 
How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples of local ID. 
Again SSI/DID/VC doesn't mean you don't need AS, those technologies can be complementary. 
 

As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO. 
What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements => the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself. 
What do you need an AS for? Then it can sign the claim to present to RS.

FI : to be sure, what is "it"? 
 
 
In this case, suppose the RO only provided consent for rs_domain/directory1 for read. 
We now need to get back to the AS to mint the access token. 
If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis. 


If we want the AS to not know about the RS, we either : 
- don't supply the rs_domain at all -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization applies. In that case I agree with your either or statement.  
Yes 
- or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity. 

FI : yes

[Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference with an OAuth 2.0 access token.

Either way, the AS has not been provided any information as to where this token will effectively be used.  


I don't think the abstract flow deals with those privacy concerns. 
To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and no AS.

[Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation is still required for more general settings of authorization.  
Please drop the next use case in the repo, so we can dive deeper into it and see how to provide both central grant negotiation and privacy.

FI : will do. 

I've added a DID example to my implementation, will publish it soon. 

 
Best regards.
/Francis
 

Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea. 

Fabien 

Le mar. 11 août 2020 à 05:58, Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org> a écrit :
Hello Denis,

what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.

BTW, I can't understand the role of an "Orchestrator" (which is left undefined).


+-----------+      +--------------+  +-----------+  +----+  +---------------------+
| Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource Controller |
| is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is          |
|   Staff   |      | Registr. App |  | Server    |  | AS |  |       Student       |
+-----------+      +--------------+  +-----------+  +----+  +---------------------+
  |(1) RegisterStudent    |                |           |                |
  |---------------------->|                |           |                |
  |                       |(2) RequestRecordIntent(RecordType,StudentId,
  |                       |     OrchestratorId):AuthRequest[RecordType,StudentId]
  |                       |<-------------->|           |                |
  |                       |                |           |                |
  |                       |(3) AuthZRequest(RecordType,StudentId,OrchestratorId)
  |                       |--------------------------->|                |
  |                       |                |           |(4) ConsentRequest(RecordType,
  |                       |                |           |     OrchestratorId):Consent
  |                       |                |           |<-------------->|
  |                       |(5) AuthZ[RecordType,StudentId,OrchestratorId]
  |                       |<---------------------------|                |
  |                       |                |           |                |
  |                       |(2) RequestRecord(RecordType,StudentId,OrchestratorId)
  |                       |     :RecordOf[StudentId]   |                |
  |                       |<-------------->|           |                |
  |(7) Registered         |                |           |                |
  |<----------------------|                |           |                |
  +                       +                +           +                +

we assume the authz request sent by "Client" to "AS" describes the protected resource without referring to the authz server. An AS can issue the authz to release the graduation record  of a student ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to the target university. 

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable  by the resource server.
- OrchestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
- StudentId must be known to RS, AS and Orchestrator.

Therefore, the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.

What privacy problem do you see here?

[Denis] The User, a physical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? :-)

Denis


Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis


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


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


--------------5400C7BDA7257099DD08F360-- From nobody Wed Aug 12 07:39:11 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 D89E03A12EA for ; Wed, 12 Aug 2020 07:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 0xfLbjlBJeeN for ; Wed, 12 Aug 2020 07:39:06 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 18B133A13CE for ; Wed, 12 Aug 2020 07:38:19 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id b17so2781001ion.7 for ; Wed, 12 Aug 2020 07:38:19 -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=akkVideKbw/jAtBOKEUNji2A4WNkj2Hyr++SzWyfNc0=; b=XrgGTvRNgv4WHItdYyR0N+b9UhGPkIRmGRgGT3hK+OKgEBl20Aft7gYIm8rvAOsk6u pZ4OLrjpy0zsS1+wVawzqZaM4+RAPuWCJXWe0CVaHb+Ys27BAJ4u8YA98zuT2onq29+B BcyBkbELYRgbg/vDfEEi3j3HYkXI7O7enxoMc018awm5oWCcRJ+gSzNtlcvvBTCY5Z+4 NHcf8syyZXZlmM9pRsDlgLSRtE6QKALdgro82cPj7FlnwFSFuqi6xwxjHUdwHJFHQio0 cIVHhSe4FamROL9MDQoGrFsP1zx6eejHxwmoFWLaIrHGjr626X8Uh+1eawFS87eUUQA1 nJNQ== 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=akkVideKbw/jAtBOKEUNji2A4WNkj2Hyr++SzWyfNc0=; b=YISetP2Cne06lsmsNGP5dTAXgGpNuqgSYBYuRxT8tvjoGT67oENBrqXPxr3YRvBch0 ShkAoiUf4QZN29NUZoAU049NArjG7DVaxBjoB0uQsV6HOVkQps5NsMaJaUhuHcyUd7pV z4zkd6PIwxG5YXfDGX675j0F5qfxtLp/6XvTWgNeSZwScDRfvQhIjmyDbvPrlakgdiD4 PrWOpOi3nsZugz9YAZitMiZSrMjiW6aAkfGH4VqS0VOgWociq0MjwRfIpD6zlxXwEERD 04VTWKFmwZS6whU+qvQhalBqwGlFcIStx94JkomH31OpZFraqGUHttRbMPm2xdPyXtiN jcvA== X-Gm-Message-State: AOAM530rn2Mg3YJJvUMoj4a2whNOhWZDeHSuDZfAV78bPznRNz2+aDUe 9sz88b1QzPz33tYWwGv+NxwRw9bSWpGMM+zBjFw= X-Google-Smtp-Source: ABdhPJy9NG2LXw0yspzj/7p7SgX9NxocNv0C3w+6R9Ippk+MZ8Fh6g+oJU4Fcz5Xy8F2PIRh7ahwknRWSr2GNOV5PFk= X-Received: by 2002:a6b:e70d:: with SMTP id b13mr62755ioh.141.1597243098304; Wed, 12 Aug 2020 07:38:18 -0700 (PDT) MIME-Version: 1.0 References: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> In-Reply-To: From: Fabien Imbault Date: Wed, 12 Aug 2020 16:38:07 +0200 Message-ID: To: Denis Cc: Francis Pouatcha , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000007e961005acaf23a1" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 14:39:10 -0000 --0000000000007e961005acaf23a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks that's clear now. Then it's not a signature, it's just a hash. Thanks Fabien On Wed, Aug 12, 2020 at 4:35 PM Denis wrote: > Hi Fabien, > > Thanks Denis. > > A few questions to clarify: > - "the field included into the access token will look like a random numbe= r > to the RS." - you mean AS? > > Correct. This was a typo. > > - "It should have two parts : a signed part and an unsigned part." - > Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (wit= h > short expiry) between the temporary_id and the url, on the RS side? > > Sorry, I am not aware of this scheme. > > Then the algorithm would be : > 1. Client contacts the RS, which sends a resource description > (temporary_id) > > No. It is not a temporary_id. > > 2. The flow continues and a token is generated, using the temporary_id. > > No. Knowing the true identifier of the RS, the Client picks a > random_number and computes a concealed_target_identifier =3D hash > (random_number, RS_identifier). > > While requesting an access token, the Client asks the AS to include the > concealed_target_identifier into the access token. > > While sending the access token, the Client adds the random_number into th= e > unsigned part of the access token. > > While receiving the access token, the RS uses it own RS_identifier and > retrieves the random_number placed into the unsigned part of the access > token. > It then computes a hash of (random_number, RS_identifier). If the result > matches with the concealed_target_identifier placed into the signed part = of > the access token, then the access token is well targeted, otherwise it is > ignored. > > 3. Client makes the call to the RS, using the token. The RS verifies the > signature + it also verifies that the mapping is the one expected. > > BTW, it makes the RS decide the maximum token expiry. > > Token expiration is unrelated. > > The issue is that it requires more work on the RS side, compared to a > stateless JWT. > > Adding two computations using a one way hash function is not a big deal. > > Is that correct? > > No. The mechanism is fairly different. It has already been explained once > on the OAuth mailing list. > > Denis > > > Fabien > > > On Wed, Aug 12, 2020 at 3:24 PM Denis wrote: > >> With so many messages in the last 24 hours, I can't respond to all of >> them at once. >> I picked the last one first. >> >> Inline too :-) >> >> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha wrote: >> >>> Hello Fabian, inline >>> >>> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> My comments are embedded into your email with FI. >>>> >>>> You're saying in a follow-up message: >>>> "- If you want privacy, *don't* expose RS identity to AS. >>>> - If you want transparency, expose RS identity to AS. >>>> You can't have both...." >>>> While that may seem a reasonable dichotomy at first sight, I believe >>>> the reality is actually more nuanced and depends on how we end up desi= gning >>>> the system. >>>> >>> [Denis] This is in fact more nuanced. It is possible to prevent the AS >> to know who the RS is by hiding the true identifier of the RS to the AS. >> >> This means that for security reasons the access token is still targeted >> but that the field included into the access token will look like a rando= m >> number to the RS. >> That random number will change for every access token. >> >> In order for the RS to make sure that the access token is indeed intende= d >> for itself, it will need to combine the field included into the access >> token >> with an unsigned field external to the access token. >> >> This would have a major consequence for the structure of a GNAP access >> token that will be rather different from an OAuth 2.0 access token. >> It should have two parts : a signed part and an unsigned part. >> >> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha >>>> wrote: >>>> >>>>> Hello Fabian, >>>>> >>>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I think Denis points to the fact that, in the current situation, the >>>>>> AS receives the resource request from the Client and therefore knows= what >>>>>> tokens are asked. >>>>>> >>>>> The token request must not mention any reference of the RS. >>>>> >>>> >>>> FI : yes we can do that, but as Tom commented, it's not a general rule= . >>>> And for instance in XYZ you do describe the URL of the resource. See a= lso >>>> the use case on directed tokens, which is an interesting topic which m= akes >>>> sense in many scenarios. >>>> >>> Yes. But disclosing the protected resource discloses the RS. >>> >> >> FI : yes of course. Which is why RS hiding may be a solution. >> >>> >>> But as soon as you include that possibility, it's fair to think that >>>> this capability could be used for surveillance purposes in some cases, >>>> unless you found a privacy by design scheme that applies by default. >>>> >>> Yes. THen default shall be using URI of resource description and not UR= L >>> to indicate resource location. >>> >> >> FI : yes >> >>> >>> Again this doesn't mean that transparency requirements aren't important >>>> too, but I think there are other ways it can be achieved (for instance= , an >>>> inspiration is the certificate transparency project). Could be an exte= nsion >>>> to the protocol I believe. >>>> >>> The certificate transparency deals with something else. Does not fit in >>> this context at all. >>> >>> >> FI : It does, and has already been implemented by some projects in >> relationship with OAuth2, as an additional component. >> >>> >>>> >>>>> >>>>>> Then it also implements the consent interface (and possibly the logi= n >>>>>> too) and so it also knows who validates and what is accepted or not. >>>>>> >>>>> Decoupling this does not change the privacy context, as the AS issues >>>>> the Token. AS needs to add a reference to the RC in the token. SO AS = can >>>>> correlate on StudentId anyway. >>>>> >>>> >>>> FI : I disagree. It does change the privacy context, if as Denis >>>> suggested, the consent is made outside of the AS and if you don't send= to >>>> the AS the information on the RS when it needs to issue the token. >>>> Correlation on StudentId is limited as long as it's a local identifier= , >>>> i.e. not a public DID. >>>> >>> How local can the StudentId be? It is known to both universities and to >>> the AS. Without a public reference, you can not link information betwee= n >>> unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Th= en >>> you do not need central AS anymore. >>> >> >> FI : see keri or peer DID for instance, as examples of local ID. >> Again SSI/DID/VC doesn't mean you don't need AS, those technologies can >> be complementary. >> >> >>> >>>> As a concrete example: a user may want to use an application to access >>>> rs_domain/directory1 and rs_domain/directory2 in read and write, which= are >>>> managed by a RO. >>>> What I suggested is that the Client may (optionally) carry out its >>>> consent through a decoupled IS server (separated from the AS), that >>>> displays the UI based on the RS requirements =3D> the IS knows what >>>> information is used, but the IS may be chosen by the IS independently = from >>>> the AS or even run by the Client itself. >>>> >>> What do you need an AS for? Then it can sign the claim to present to RS= . >>> >> >> FI : to be sure, what is "it"? >> >> >>> >>> >>>> In this case, suppose the RO only provided consent for >>>> rs_domain/directory1 for read. >>>> We now need to get back to the AS to mint the access token. >>>> >>> If AS mint access token, AS will be able to correlate. Unless start >>> applying intransparent complex reference mapping techniques, wich might >>> even open room for new attack vectors. >>> >> >> FI : not necessarily with respect to correlation, see above. >> As for mapping techniques, this is the very reason of my question to >> Denis. >> >>> >>> >>>> If we want the AS to not know about the RS, we either : >>>> - don't supply the rs_domain at all -> the JWT says that directory1 in >>>> read access is authorized. The downside is that we actually cannot con= trol >>>> to which URL the authorization applies. In that case I agree with your >>>> either or statement. >>>> >>> Yes >>> >>>> - or find a way to hide it (not sure if that's practical, hence my >>>> questions on RS hiding). This would have the benefit of still allowing >>>> directed tokens -> the JWT says that rs_petname/directory1 in read acc= ess >>>> is authorized. >>>> >>> More complexity. >>> >> >> FI : yes >> >> [Denis] As indicated at the top of this email, it is possible to always >> hide the identifier of the RS while still targetting every access token. >> >> BTW, I have expanded the notion of targetting by allowing to place into = a >> target field of an access token either or both a RS identifier and >> a Service Name (SN) identifier to which the RS belongs. >> >> Two targetting fields should hence be possible: a RS identifier and a SN >> identifier. >> >> This is also a difference with an OAuth 2.0 access token. >> >> Either way, the AS has not been provided any information as to where thi= s >>>> token will effectively be used. >>>> >>> >>>>> >>>>>> I don't think the abstract flow deals with those privacy concerns. >>>>>> >>>>> To solve the privacy problem addressed in this thread, we need to go >>>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to is= sue a >>>>> VC (Verifiable Credential) to the Student (in his role of RC). The St= udent >>>>> will then present this claim to UNIV-1 during his registration. In th= is >>>>> case we need no Grant negotiation and no AS. >>>>> >>>> [Denis] This is a complete redesign of my example and hence this >> redesign has no relationship with my example. >> >> >>>> FI : That may be useful but it's not enough. What you describe only >>>> works because you take a very specific use case, aka registration. Thi= s >>>> fits well into DID/VC without requiring authorization per say. However >>>> grant negotiation is still required for more general settings of >>>> authorization. >>>> >>> Please drop the next use case in the repo, so we can dive deeper into i= t >>> and see how to provide both central grant negotiation and privacy. >>> >> >> FI : will do. >> >>> >>> I've added a DID example to my implementation, will publish it soon. >>>> >>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>>> >>>>>> Then I agree with you on the audience field of the token, if left >>>>>> empty it simplifies part of the problem, although it removes a big p= art of >>>>>> the control you may want from directed tokens. That's why I'm willin= g to >>>>>> better develop the RS hiding idea. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>>> >>>>>>> Hello Denis, >>>>>>> >>>>>>> what you describe in the use case seems to be the default behavior >>>>>>> of the protocol. Let me map it with this abstract protocol flow: >>>>>>> >>>>>> [Denis] The redesign below has no relationship with my use case. >> >> A key element of my design is the User, i.e. a physical person which >> initiates the exchanges. In the example below the User has disappeared. >> >> A User is not a role, but an entity. >> >> BTW, I can't understand the role of an "Orchestrator" (which is left >> undefined). >> >> >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>>> Resource Controller | >>>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>>> is | >>>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>>> Student | >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> |(1) RegisterStudent | | | >>>>>>> | >>>>>>> |---------------------->| | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>>> | | >>>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(3) >>>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>>> | |--------------------------->| >>>>>>> | >>>>>>> | | | |(4) >>>>>>> ConsentRequest(RecordType, >>>>>>> | | | | >>>>>>> OrchestratorId):Consent >>>>>>> | | | >>>>>>> |<-------------->| >>>>>>> | >>>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>>> | |<---------------------------| >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>>> | | :RecordOf[StudentId] | >>>>>>> | >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> |(7) Registered | | | >>>>>>> | >>>>>>> |<----------------------| | | >>>>>>> | >>>>>>> + + + + >>>>>>> + >>>>>>> >>>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>>> protected resource without referring to the authz server. An AS can= issue >>>>>>> the authz to release the graduation record of a student >>>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refer= ence to >>>>>>> the target university. >>>>>>> >>>>>>> What matters for this authz object is: >>>>>>> - StudentId: a reference to the student as known to the resource >>>>>>> server. >>>>>>> - RecordType: a reference to a resource of type graduation record a= s >>>>>>> understandable by the resource server. >>>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bin= d >>>>>>> authz to Orchestrator. >>>>>>> >>>>>>> But: >>>>>>> - RS must trust AS issued token. >>>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>>> >>>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>>> field empty. >>>>>>> >>>>>>> Same principle applies for the second use case. >>>>>>> >>>>>>> What privacy problem do you see here? >>>>>>> >>>>>> [Denis] The User, a physical person which initiates the exchanges ha= s >> disappeared. >> No more user, no more privacy issues ? :-) >> >> Denis >> >> >>>>>>> Best regards. >>>>>>> /Francis >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>>> >>>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>>> directory, but I failed. >>>>>>>> >>>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>>> second try: >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-u= se-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> -- >>> 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 >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007e961005acaf23a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks that's clear now.
Then it's not a signa= ture, it's just a hash.=C2=A0

Thanks
Fabien

On Wed, Aug 12, 2020 at 4:35 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hi=C2=A0 Fabien,
=20
Thanks Denis.

A few questions to clarify:=C2=A0
- "the field included into the access token will look like a random number to the RS." - you mean AS?

Correct. This was a typo.

- "It should have two parts : a signed part and an unsigned part." - Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with short expiry) between the temporary_id and the url, on the RS side?

Sorry, I am not aware of this scheme.

Then the algorithm would be :
1. Client contacts the RS, which sends a resource description (temporary_id)

No. It is not a temporary_id.=C2=A0

2. The flow continues and a token is generated, using the temporary_id.

No. Knowing the true identifier of the RS, the Client picks a random_number and computes a concealed_target_identifier =3D=C2=A0 ha= sh (random_number, RS_identifier).

While requesting an access token, the Client asks the AS to include the concealed_target_identifier into the access token.

While sending the access token, the Client adds the random_number into the unsigned part of the access token.

While receiving the access token, the RS uses it own RS_identifier and retrieves the random_number placed into the unsigned part of the access token.
It then computes a hash of (random_number, RS_identifier). If the result matches with the concealed_target_identifier placed into the signed part of
the access token, then the access token is well targeted, otherwise it is ignored.

3. Client makes the call to the RS, using the token. The RS verifies the signature=C2=A0+ it also verifies that the mapping is the one expected.=C2=A0=C2=A0

BTW, it makes the RS decide the maximum token expiry.

Token expiration is unrelated.

The issue is that it requires more work on the RS side, compared to a stateless JWT.=C2=A0

Adding two computations using a one way hash function is not a big deal.

=C2=A0Is that correct?

No. The mechanism is fairly different. It has already been explained once on the OAuth mailing list.

Denis


Fabien


On Wed, Aug 12, 2020 at 3:2= 4 PM Denis <denis.ietf@free.fr> wrote:
With so many messages in the last 24 hours, I can't respond to all of them at once.
I picked the last one first.

Inline too :-)

On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
Hi Francis,=C2=A0

My comments are embedded into your email with FI.

You're saying in a follow-up message:=C2=A0
"- If you want privacy,=C2=A0d= on't=C2=A0expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem=C2=A0a reasonable=C2=A0dichotomy=C2=A0at first s= ight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access token.

In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token.

This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case=C2=A0on directed tokens= , which is an interesting topic which makes sense in many scenarios.=C2=A0=C2= =A0
Yes. But disclosing the protected resource discloses the RS.=C2=A0

FI : yes of course. Which is why RS hiding may be a solution.=C2=A0

But as soon as you include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default.=C2=A0
Yes. THen default shall be using URI of resource description and not URL to indicate resource location.=C2=A0

FI : yes=C2=A0

Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe.=C2=A0
The certificate transparency deals with something else. Does not fit in this context at all.
=C2=A0
FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component.=C2=A0

=C2=A0
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the=C2=A0RC in the token. SO AS can correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to th= e AS the information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID.=C2=A0
How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples of local ID.=C2=A0
Again SSI/DID/VC doesn't mean you don't ne= ed AS, those technologies can be complementary.=C2=A0
=C2=A0

As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO.=C2=A0
What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements =3D> the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself.=C2=A0
What do you need an AS for? Then it can sign the claim to present to RS.

FI : to be sure, what is "it"?=C2=A0
=C2=A0
=C2=A0
In this case, suppose the RO only provided consent for rs_domain/directory1 for read.=C2=A0
We now need to get back to the AS to mint the access token.=C2=A0
If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis.=C2=A0


If we want the AS to not know about the RS, we either :=C2=A0
- don't supply the rs_domain at al= l -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization=C2=A0applies. In that case = I agree with your either or statement.=C2= =A0=C2=A0
Yes=C2=A0
- or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity.=C2=A0

FI : yes

[Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference with an OAuth 2.0 access token.

Either way, the AS has not been provided any information as to where this token will effectively be used.=C2= =A0=C2=A0


I don't thi= nk the abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and=C2=A0= no AS.

[Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation=C2=A0is still required for mo= re general settings of authorization.=C2=A0= =C2=A0
Please drop the next use case in the=C2=A0repo, so we can dive deeper into it an= d see how to provide both central grant negotiation=C2=A0and privacy.

FI : will do.=C2=A0

I've added a DID example to my implementation, will publish it soon.=C2= =A0

=C2=A0
Best regards.
/Francis
=C2=A0

Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea.=C2= =A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@d= marc.ietf.org> a =C3=A9crit=C2=A0:
Hello=C2=A0Den= is,

what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.

BTW, I can't understand the ro= le of an "Orchestrator" (which is left undefined).=


+-----------+=C2=A0 =C2=A0 =C2=A0 +--------= ------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+----------------= -----+
| Requestor |=C2=A0 =C2= =A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|= =C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0o= r |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |= =C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2= =A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+----------------= -----+
=C2=A0 |(1) RegisterStudent=C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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|(2= ) RequestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0OrchestratorId):A= uthRequest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------------= -->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 =C2=A0 =C2=A0 =C2=A0|(3= ) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|----------------= ----------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =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) ConsentRequest(RecordTy= pe,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):C= onsent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<------------= -->|
=C2=A0 |=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=A0AuthZ[R= ecordType,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------------= ---------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= (2) RequestRecord(RecordT= ype,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0:RecordOf[Stude= ntId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------------= -->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<= br> =C2=A0 |(7) Registered= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |<------------------= ----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +

we assume the authz request sent by "Client" to &qu= ot;AS" describes the protected resource without referring=C2=A0to the authz server. An AS can issue the authz to release the graduation record=C2=A0 o= f a student ((5)=C2=A0AuthZ[RecordTyp= e,StudentId,OrchestratorId]), without any reference to the target university.=C2=A0<= /div>

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable=C2=A0 by t= he resource server.
-=C2=A0OrchestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2=A0Orchestrator.=

Therefore, the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.

What privacy problem do you see here?

[Denis] The User, a physical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? :-)

Denis


Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@fre= e.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-gnap/genera= l/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privac= y-by-Design%22-(PbD)

Denis


--
Francis Pouatcha
Co-Founder and Technical Lead


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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007e961005acaf23a1-- From nobody Wed Aug 12 08:24:17 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 6544B3A1365 for ; Wed, 12 Aug 2020 08:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 kIAZbGvqEl5g for ; Wed, 12 Aug 2020 08:24:14 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9223A0F74 for ; Wed, 12 Aug 2020 08:24:14 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CFOBZa008007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 11:24:12 -0400 From: Justin Richer Message-Id: <5B49BD4E-9EE5-4B8B-A24C-981E579726A9@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E1EFEDEE-F766-4982-AD4B-F3AC8887907E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 11:24:11 -0400 In-Reply-To: Cc: Yaron Sheffer , GNAP Mailing List To: Francis Pouatcha References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Design team formed 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: Wed, 12 Aug 2020 15:24:16 -0000 --Apple-Mail=_E1EFEDEE-F766-4982-AD4B-F3AC8887907E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Francis, The design team is just a temporary construct to get things started = here, and it will dissolve back into the WG when the task is over. I, = for one, am really thankful to have you bring your experience to this = working group. I=E2=80=99ve appreciated your contributions greatly so = far, and I look forward to continuing to work with you. We still have a long way to go and a lot of work to do. The output of = the design team is just the start of the working group, and there are = many more things to figure out. =E2=80=94 Justin > On Aug 11, 2020, at 1:25 PM, Francis Pouatcha = wrote: >=20 > It is unfortunate I didn't make it. Would have liked to bring in my 22 = years of experience in building authz applications. >=20 > Best regards. > /Francis >=20 > On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer > wrote: > Thank you all for attending the inaugural GNAP meeting at IETF-108. We = had quite a few volunteers, and the chairs picked the following people = for the design team: >=20 > * Kathleen Moriarty > * Justin Richer > * Dick Hardt > * Mike Jones > * Fabien Imbault >=20 > Kathleen has graciously agreed to convene the sessions and report on = the team's outcome. Thank you all who volunteered! >=20 > We expect the design team to decide on a solution outline that = combines the best of both proposals, and present this outline by Sep. = 15. Anything is as usual subject to approval by the whole working group. >=20 > Thanks, > Leif and Yaron >=20 >=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ = --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_E1EFEDEE-F766-4982-AD4B-F3AC8887907E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Francis,

The design team is just a temporary construct to get things = started here, and it will dissolve back into the WG when the task is = over. I, for one, am really thankful to have you bring your experience = to this working group. I=E2=80=99ve appreciated your contributions = greatly so far, and I look forward to continuing to work with = you.

We still = have a long way to go and a lot of work to do. The output of the design = team is just the start of the working group, and there are many more = things to figure out.

 =E2=80=94 Justin

On Aug = 11, 2020, at 1:25 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

It is unfortunate I didn't make = it. Would have liked to bring in my 22 years of experience in building = authz applications.

Best regards.
/Francis

On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:
Thank you all for attending the = inaugural GNAP meeting at IETF-108. We had quite a few volunteers, and = the chairs picked the following people for the design team:
=
* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the = team's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines = the best of both proposals, and present this outline by Sep. 15. = Anything is as usual subject to approval by the whole working group.

Thanks,
        Leif and Yaron



--
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/
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_E1EFEDEE-F766-4982-AD4B-F3AC8887907E-- From nobody Wed Aug 12 08:32:02 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 EE9183A13FB for ; Wed, 12 Aug 2020 08:32:00 -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 6PtPjYq_C53e for ; Wed, 12 Aug 2020 08:31:59 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 2C0D93A13FC for ; Wed, 12 Aug 2020 08:31:59 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id p20so2466712wrf.0 for ; Wed, 12 Aug 2020 08:31:58 -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=1D/I28IQGv3oEPeWuuS9Ye9yCGYrbs3V0390dgnxfko=; b=i7Yr2POzLSvaK3gcsxqRVMFnjTtfLbnzy+qD6d7njx/E3OkJS5GLaVA1NKDjJz3eYf emw2MoiTYn91sOPuQNpq3DAlegOHM2zz2FrBX13BwTsbmnwWVEJ+iKxu7jrpYI5F8CQG XICvPapTzuJ3WDvR2u1nrabWWsmZy/n/ozWIQ= 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=1D/I28IQGv3oEPeWuuS9Ye9yCGYrbs3V0390dgnxfko=; b=JXAKHbMvA3De6RiTTUvArCflx2uvqhdIsqcWMC38qiauO7zqsnVSRUEPs1p5MFG3Ej uDnT+eXyu0JfFXr52jVqjyZti0Vl5J9W+rCGARQIftLxDuw6h2yIFkA4i7Mm7nhL6rtB fA8ebpCXjLUB6bvbQ4C1Lry4VZrdLLWA+aLfEdMlMnwKa+PVbOb/NM3z8ke+mRWGnmsO L+hAe9TJ/xyNdm5BYndwP1DeTTQ+r+gho24xRhlr+i8IR26MwZTC8SnzEaJcxRefSIF5 tkDm/F+P4GvWRT6wPSeWnmKPq5Q/yu5zq687XaKpbBzjYWHsr9kyYcquh8IqUiB2jZ4T UOAA== X-Gm-Message-State: AOAM5324Wtvq1R8qOl0A5Dop6AQHTGEt7tMFcEn7v11ch3ZmLTvEhBc7 4AHbVVuLi5his2fJoGGLXKQytV47a7TdKj8wIt1IEw== X-Google-Smtp-Source: ABdhPJwzVZGzqrzD/qapXtvwJ+nEIr8k3ux7UWfvQNPVfs/Sh/VDzJqLMXH2d+LbSElCr/WKPlCjhhFmTEwWxEu8CXs= X-Received: by 2002:a5d:51c3:: with SMTP id n3mr208459wrv.104.1597246317421; Wed, 12 Aug 2020 08:31:57 -0700 (PDT) MIME-Version: 1.0 References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> <5B49BD4E-9EE5-4B8B-A24C-981E579726A9@mit.edu> In-Reply-To: <5B49BD4E-9EE5-4B8B-A24C-981E579726A9@mit.edu> From: Francis Pouatcha Date: Wed, 12 Aug 2020 11:31:46 -0400 Message-ID: To: Justin Richer Cc: Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005e7cb405acafe397" Archived-At: Subject: Re: [GNAP] Design team formed 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: Wed, 12 Aug 2020 15:32:01 -0000 --0000000000005e7cb405acafe397 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, Thanks for your response. I hope the design team will keep addressing essential topics on the list so we can contribute. Best regards. /Francis On Wed, Aug 12, 2020 at 11:24 AM Justin Richer wrote: > Francis, > > The design team is just a temporary construct to get things started here, > and it will dissolve back into the WG when the task is over. I, for one, = am > really thankful to have you bring your experience to this working group. > I=E2=80=99ve appreciated your contributions greatly so far, and I look fo= rward to > continuing to work with you. > > We still have a long way to go and a lot of work to do. The output of the > design team is just the start of the working group, and there are many mo= re > things to figure out. > > =E2=80=94 Justin > > On Aug 11, 2020, at 1:25 PM, Francis Pouatcha < > fpo=3D40adorsys.de@dmarc.ietf.org> wrote: > > It is unfortunate I didn't make it. Would have liked to bring in my 22 > years of experience in building authz applications. > > Best regards. > /Francis > > On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer > wrote: > >> Thank you all for attending the inaugural GNAP meeting at IETF-108. We >> had quite a few volunteers, and the chairs picked the following people f= or >> the design team: >> >> * Kathleen Moriarty >> * Justin Richer >> * Dick Hardt >> * Mike Jones >> * Fabien Imbault >> >> Kathleen has graciously agreed to convene the sessions and report on the >> team's outcome. Thank you all who volunteered! >> >> We expect the design team to decide on a solution outline that combines >> the best of both proposals, and present this outline by Sep. 15. Anythin= g >> is as usual subject to approval by the whole working group. >> >> Thanks, >> Leif and Yaron >> >> >> >> -- >> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000005e7cb405acafe397 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin,

Thanks for your=C2=A0response. = I hope the design team will keep addressing essential topics on the list so= we can contribute.

Best regards.
/Franc= is

On Wed, Aug 12, 2020 at 11:24 AM Justin Richer <jricher@mit.edu> wrote:
Francis,

The design team is just a temporary construct = to get things started here, and it will dissolve back into the WG when the = task is over. I, for one, am really thankful to have you bring your experie= nce to this working group. I=E2=80=99ve appreciated your contributions grea= tly so far, and I look forward to continuing to work with you.
We still have a long way to go and a lot of work to do. The ou= tput of the design team is just the start of the working group, and there a= re many more things to figure out.

=C2=A0=E2=80=94= Justin

On Aug 11, 2020, at 1:25= PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
It is unfortunate I didn't make it. Would ha= ve liked to bring in my 22 years of experience in building authz applicatio= ns.

Best regards.
/Francis

On Tue, Aug 11= , 2020 at 6:43 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you all for attending the in= augural GNAP meeting at IETF-108. We had quite a few volunteers, and the ch= airs picked the following people for the design team:

* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron



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


--
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
--0000000000005e7cb405acafe397-- From nobody Wed Aug 12 08:38:22 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 B03953A13C8 for ; Wed, 12 Aug 2020 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sa2_mawdv1Ee for ; Wed, 12 Aug 2020 08:38:10 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B378D3A13A3 for ; Wed, 12 Aug 2020 08:38:09 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CFc4R0013878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 11:38:05 -0400 From: Justin Richer Message-Id: <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_66AB9901-6C1D-41D8-9E5E-B7C3ACBD1986" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 11:38:04 -0400 In-Reply-To: Cc: Dick Hardt , Denis , Benjamin Kaduk , "txauth@ietf.org" To: Francis Pouatcha References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 15:38:21 -0000 --Apple-Mail=_66AB9901-6C1D-41D8-9E5E-B7C3ACBD1986 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to this. I think that the core protocol needs to be designed to allow = this kind of action, but I also think it is possible that the details of = this could end up in an extension to the main document. I=E2=80=99ve put = a flag in the ground for this in XYZ in sections 10.3 and 10.4, which is = adapted from UMA2=E2=80=99s distributed authorization protocol: = https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10= .3 = The important detail here, in XYZ=E2=80=99s design, is that the RS has a = clear way to communicate to the client what will be needed to fulfill = the request, and the client/orchestrator/whatever has a clear way to = incorporate that into the main protocol. The details of (2) using the = XYZ pattern are: +-----------+ +--------------+ +----+ +----+ = +---------------------+ | Requestor | | Orchestrator | | | | GS | | Resource = Controller | | was | | was | | RS | | or | | was = | | User | | Client | | | | AS | | Resource Owner = | +-----------+ +--------------+ +----+ +----+ = +---------------------+ |(1) ServiceRequest | | | | |---------------------->| | | | | |(2) ServiceIntent:AuthZChallenge | | |----------->| | | | | | | | | | |(2a) Register resource set | | |------>| | | | | | | | | |(2b) Return resource reference = handle | | |<------| | | | | | | | |(2c) Return AS URL and resource reference = handle | |<-----------| | | | | | | | | |(3) AuthZRequest(AuthZChallenge, include = resource handle) | |------------------->| | Note that the client can ALSO request additional resources on top of = what the RS returned in (2b), since this is passed simply as one element = of the array.=20 =E2=80=94 Justin > On Aug 11, 2020, at 6:37 PM, Francis Pouatcha wrote: >=20 > Hello Dick, >=20 > On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt > wrote: > Hi Francis >=20 > The user is an entity, not a role in the protocol in how I am defining = roles, so steps (1) and (7) are confusing to me on what is happening. > "Requestor" is the role (was User). So the UML participant refers to = the role "Requestor" >=20 >=20 > I also think that (2) could be an extension to GNAP, rather than part = of the core protocol. > If you make it an extension, you hide. It shall rather be an optional, = integral part of the protocol. If the "Orchestrator/Negotiator/Client" = can translate the service request into a resource request, then there = will be no need to invoke (2). >=20 > When we move beyond identity management, cases become complex and it = makes sense to explicitly display this possibility in the protocol flow. >=20 > In some open banking designs,=20 > - the "Orchestrator/Negotiator/Client" will not know the AS to talk to = unless the call (2). > - the request (2) might result in an exemption, meaning no need for = further authorization, allowing to skip (3, 4, 5) and even (6). >=20 > /Francis >=20 >=20 >=20 >=20 >=20 > On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha > wrote: > In this context, I suggest we pick some words to work with, and = sharpen them as we move on, discover and map new use cases to the = protocol. >=20 > In this diagram from the original thread = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ), I replaced the words: >=20 > +-----------+ +--------------+ +----+ +----+ = +---------------------+ > | Requestor | | Orchestrator | | | | GS | | Resource = Controller | > | was | | was | | RS | | or | | was = | > | User | | Client | | | | AS | | Resource = Owner | > +-----------+ +--------------+ +----+ +----+ = +---------------------+ > |(1) ServiceRequest | | | | > |---------------------->| | | | > | |(2) ServiceIntent:AuthZChallenge | > | |<---------->| | | > | | | | | > | |(3) AuthZRequest(AuthZChallenge) | > | |------------------->| | > | | | |(4) = ConsentRequest:Grant > | | | |<-------------->| > | |(5) GrantAccess(AuthZ) | > | |<-------------------| | > | | | | | > | |(6) ServiceRequest(AuthZ):ServiceResponse > | |<---------->| | | > |(7) ServiceResponse | | | | > |<----------------------| | | | > + + + + + >=20 > The purpose of the GNAP protocol is to help negotiate access to a = protected resource. It starts with a requestor delegating activity to an = orchestrator. These are all roles, no entities. Let focus on mapping the = use cases to the protocol roles and interactions so wwe can discover = what is missing. >=20 > It seems cumbersome to use it in discussions as it is impossible to = give the word "Client" a clear definition. >=20 > We can mention in the final document, that the "Orchestrator" (or = whatever word we finally use) plays the same role as the "Client" in = oAuth2. >=20 > Best regards. > /Francis >=20 >=20 >=20 >=20 >=20 > On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt > wrote: > I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >=20 > Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >=20 > For example, clarifying that a Client is a role an entity plays in the = protocol, and that the same entity may play other roles at other times, = or some other language to help differentiate between "role" and = "entity". >=20 > /Dick > =E1=90=A7 >=20 > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >=20 > GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is ignore the fact that GNAP is going to be coming up in a world that = is already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >=20 > =E2=80=94 Justin >=20 >> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>=20 >> I think that is fundamentally part of the question: >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion >>=20 >> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>=20 >> Food for thought. >> - Warren >>=20 >>=20 >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. = Implement Authress . >>=20 >>=20 >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >> Hi Denis, >>=20 >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> >=20 >> > Since you replied in parallel, I will make a response similar to = the one=20 >> > I sent to Dick. >> >=20 >> > > Hi Denis, >> > > >> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >> > > you describe as RS2, which might in fact be an RS unto itself, is = a=20 >> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >> > > all the same as an OAuth client. I appreciate your mapping of the=20= >> > > entities below, but it makes it difficult to hold a discussion if = we=20 >> > > aren=E2=80=99t using the same terms. >> > > >> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >> > > our own terms. The bad news is that this is really hard to do. >> > > >> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions,=20 >> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >> >=20 >> > In the ISO context, each document must define its own terminology. = The=20 >> > boiler plate for RFCs does not mandate a terminology or definitions = section >> > but does not prevent it either. The vocabulary is limited and as = long as=20 >> > we clearly define what our terms are meaning, we can re-use a term = already >> > used in another RFC. This is also the ISO approach. >>=20 >> Just because we can do something does not necessarily mean that it is = a >> good idea to do so. We are clear that we are producing a protocol = that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion. If I understand correctly, a similar reasoning prompted = Dick to >> use the term "GS" in XAuth, picking a name that was not already used = in >> OAuth 2.0. >>=20 >> -Ben >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ = >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ = --Apple-Mail=_66AB9901-6C1D-41D8-9E5E-B7C3ACBD1986 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = to this. I think that the core protocol needs to be designed to allow = this kind of action, but I also think it is possible that the details of = this could end up in an extension to the main document. I=E2=80=99ve put = a flag in the ground for this in XYZ in sections 10.3 and 10.4, which is = adapted from UMA2=E2=80=99s distributed authorization protocol:

https://tools.ietf.org/html/draft-richer-transactional-authz-09= #section-10.3

The important detail here, in XYZ=E2=80=99s design, is that = the RS has a clear way to communicate to the client what will be needed = to fulfill the request, and the client/orchestrator/whatever has a clear = way to incorporate that into the main protocol. The details of (2) using = the XYZ pattern are:

+-----------+      +--------------+ =  +----+  +----+  +---------------------+
| = Requestor |      | Orchestrator |  |    | =  | GS |  | Resource Controller |
|   was  =    |      |     was    =   |  | RS |  | or |  |    =      was        =  |
|  User     |      |  =  Client     |  |    |  | AS = |  |    Resource Owner   |
+-----------+      +--------------+ =  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |    =         |       |    =             |
  = |---------------------->|            = |       |            =     |
  |          =              |(2) = ServiceIntent:AuthZChallenge     |
  = |                    =    |----------->|       |    =             |
  |     =                   |   =          |       |     =            |
  |     =                   |   =          |(2a) Register resource = set
  |              =          |          =   |------>|              =   |
  |    =                   =  |            |      =  |                = |
  |    =                   =  |            |(2b) Return resource = reference handle
  = |                    =    |            = |<------|                = |
  |    =                   =  |            |      =  |                = |
  |    =                   =  |(2c) Return AS URL and resource reference handle
  |            =            |<-----------|    =    |                = |
  |    =                   =  |            |      =  |                = |
  |          =              |(3) = AuthZRequest(AuthZChallenge, include resource handle)
 = |                    =    |------------------->|          =       |


Note that the client can ALSO request additional resources on = top of what the RS returned in (2b), since this is passed simply as one = element of the array. 

 =E2=80=94 Justin

On Aug = 11, 2020, at 6:37 PM, Francis Pouatcha <fpo@adorsys.de> = wrote:

Hello = Dick,

On Tue, Aug = 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi = Francis

The user is = an entity, not a role in the protocol in how I am defining roles, so = steps (1) and (7) are confusing to me on what is = happening.
"Requestor" is the = role (was User). So the UML participant refers to = the role "Requestor"


I also think that (2) = could be an extension to GNAP, rather than part of the core = protocol.
If you make it an = extension, you hide. It shall rather be an optional, integral part of = the protocol. If the "Orchestrator/Negotiator/Client" can translate the = service request into a resource request, then there will be no need to = invoke (2).

When= we move beyond identity management, cases become complex and it makes = sense to explicitly display this possibility in the protocol = flow.

In some = open banking designs, 
- the = "Orchestrator/Negotiator/Client" will not know the AS to talk to unless = the call (2).
- the request (2) might result in an = exemption, meaning no need for further authorization, allowing to skip = (3, 4, 5) and even (6).

/Francis





On Mon, Aug 10, 2020 at 8:04 PM Francis = Pouatcha <fpo@adorsys.de> wrote:
In this context, I suggest we pick some = words to work with, and sharpen them as we move on, discover and map new = use cases to the protocol.

In this diagram from the original thread = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/), I = replaced the words:

+-----------+  =     +--------------+  +----+  +----+ =  +---------------------+
| Requestor |    =   | Orchestrator |  |    |  | GS |  | = Resource Controller |
|   was     |      = |     was      |  = | RS |  | or |  |        =  was         |
|  User    =  |      |   Client    =  |  |    |  | AS |  |    = Resource Owner   |
+-----------+    =   +--------------+  +----+  +----+ =  +---------------------+
  |(1) = ServiceRequest     |          =   |       |          =       |
  = |---------------------->|            = |       |            =     |
  |          =              |(2) = ServiceIntent:AuthZChallenge     |
  = |                    =    |<---------->|       |  =               |
  = |                    =    |            |    =    |                = |
  |              =          |(3) = AuthZRequest(AuthZChallenge)     |
  = |                    =    |------------------->|          =       |
  |        =                |    =         |       |(4) = ConsentRequest:Grant
  |        =                |    =         |      =  |<-------------->|
  |    =                   =  |(5) GrantAccess(AuthZ)            =    |
  |          =             =  |<-------------------|            =     |
  |          =              |      =       |       |      =           |
  |    =                   =  |(6) ServiceRequest(AuthZ):ServiceResponse
  = |                    =    |<---------->|       |  =               |
  = |(7) ServiceResponse    |          =   |       |          =       |
  = |<----------------------|            = |       |            =     |
  +          =              +      =       +       +      =           +

The purpose of the GNAP protocol is to help negotiate access = to a protected resource. It starts with a requestor delegating activity to an = orchestrator. These are all roles, no entities. Let focus on mapping the = use cases to the protocol roles and interactions so wwe can discover = what is missing.

It seems cumbersome to use it = in discussions as it is impossible to give the word "Client" a clear = definition.

We can mention in the = final document, that the "Orchestrator" (or whatever word we finally = use) plays the same role as the "Client" in oAuth2.

Best = regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick = Hardt <dick.hardt@gmail.com> wrote:
I agree = with Justin. Redefining well used terms will lead to significant = confusion. If we have a different role than what we have had in the = past, then that role should have a name not being used already in OAuth = or OIDC.

Given what = we have learned, and my own experience explaining what a Client is, and = is not, improving the definition for Client could prove useful. I am not = suggesting the term be redefined, but clarified. 

For example, clarifying = that a Client is a role an entity plays in the protocol, and that the = same entity may play other roles at other times, or some other language = to help differentiate between "role" and "entity".

/Dick
3D""=E1=90=A7

On Wed, Aug = 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I=E2=80=99m in favor = of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m = not really in favor of taking an existing term and applying a completely = new definition to it. In other words, I would sooner stop using = =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and = accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as = meaning something completely different. We did this in going from OAuth = 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsume= r=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use = the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserve= r=E2=80=9D on its own but instead always qualifies it with = =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource = Server=E2=80=9D.

GNAP = can do something similar, in my opinion. But what we can=E2=80=99t do is = ignore the fact that GNAP is going to be coming up in a world that is = already permeated  by OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance!

 =E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad = <wparad@rhosys.ch> wrote:

I think that is = fundamentally part of the question:
We are clear that we are producing a = protocol that is
conceptually (if not more strongly) = related to OAuth 2.0, and reusing terms
from OAuth 2.0 but = with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, = then we should not change the meanings of any definition. If we are = saying this supersedes or replaces what OAuth 2.0 creates, then we = should pick the best word for the job and ignore conflicting meanings = from OAuth 2.0. I have a lot of first hand experience of industries = "ruining words", and attempting to side-step the problem rather than = redefining the word just confuses everyone as everyone forgets the = original meaning as new documents come out, but the confusion with the = use of a non-obvious word continues.

Food for thought.
- = Warren

Warren Parad
Founder, = CTO
Secure your user data and = complete your authorization architecture. Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin = Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

-- =
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
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/

= --Apple-Mail=_66AB9901-6C1D-41D8-9E5E-B7C3ACBD1986-- From nobody Wed Aug 12 08:58: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 802D73A1383 for ; Wed, 12 Aug 2020 08:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 L5nA6OHeSNdv for ; Wed, 12 Aug 2020 08:58:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9A43A137F for ; Wed, 12 Aug 2020 08:58:02 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CFvtYc021735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 11:57:56 -0400 From: Justin Richer Message-Id: <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_34F7C005-21F1-4AC0-A82E-E552B079219C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 11:57:55 -0400 In-Reply-To: Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" To: Dick Hardt References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Terminology 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: Wed, 12 Aug 2020 15:58:08 -0000 --Apple-Mail=_34F7C005-21F1-4AC0-A82E-E552B079219C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What is being granted is access to something. This makes sense in terms = of rights bound to an access token, but I would argue it makes less = sense for things returned directly. Since you and I also disagree on whether returning things directly is an = important distinction (even though both the XAuth and XYZ proposals make = this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d = want to extend the notion of =E2=80=9Cgrant=E2=80=9D to include anything = and everything in the request and response.=20 I am arguing for it being more specific and precise. =E2=80=94 Justin > On Aug 11, 2020, at 6:08 PM, Dick Hardt wrote: >=20 > A grant is whatever the client is asking from the server. Currently we = have access to resources and identity claims. It could contain anything = else an extension adds that a client may request from a server. >=20 > Given the definition of grant that I included, why is grant not the = right term to use for this? >=20 >=20 > On Tue, Aug 11, 2020 at 1:35 PM Justin Richer > wrote: > I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said = that your definition of it was problematic. Namely, the desire to lump = in claims about the user into the definition of the =E2=80=9Cgrant=E2=80=9D= .=20 >=20 > =E2=80=94 Justin >=20 >> On Aug 11, 2020, at 3:49 PM, Dick Hardt > wrote: >>=20 >> I agree that orchestrator may be a role in the protocol -- it is not = a role in XYZ or XAuth today. >>=20 >> Justin: would you explain why you think the term "grant" is = problematic? It is in the WG name! >>=20 >> The client is receiving more than access to resources from the GS, it = is also receiving claims, so "client of the resource" is too limiting. >>=20 >> Reading the definition of grant[1], it fits as a verb of what the GS = is doing, and fits as a noun of what the GS provides to the client. >>=20 >> A Grant Server is an Authorization Server in OAuth, and an OpenID = Provider in OpenID Connect. >> The Grant Client is a Client in OAuth, and a Relying Party in OpenID = Connect. >>=20 >> Having new terms (GS and GC) in GNAP, separating the roles from OAuth = and OpenID Connect. >> It is straightforward to know what a GC and GS do when you understand = that a grant is a combination of resource access (from OAuth) and claims = (from OpenID Connect). >>=20 >> /Dick >>=20 >> [1] https://www.dictionary.com/browse/grant = >> verb (used with object) >> to bestow or confer, especially by a formal act: >> to grant a charter. >> to give or accord: >> to grant permission. >> to agree or accede to: >> to grant a request. >> to admit or concede; accept for the sake of argument: >> I grant that point. >> SEE MORE >> noun >> something granted, as a privilege or right, a sum of money, or a = tract of land: >> Several major foundations made large grants to fund the research = project. >> the act of granting. >>=20 >>=20 >> [1]=20 >>=20 >>=20 >>=20 >> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer > wrote: >> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what = the classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but = the term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser = agent=E2=80=9D concept that=E2=80=99s been brought up here before, so = I=E2=80=99m inclined to believe it can be a separate role from the = client. >>=20 >> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing = as it is not a =E2=80=9Cclient of the grant=E2=80=9D but rather a = =E2=80=9Cclient of the resource=E2=80=9D. >>=20 >> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Aug 11, 2020, at 3:25 PM, Dick Hardt > wrote: >>>=20 >>> I echo Mike's comments on preserving names when possible. The shift = from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >>>=20 >>> I also echo Tom's comments about separating Entities from Roles. >>>=20 >>> Orchestration[1] in my opinion is not what the "client" is doing. >>>=20 >>> Below is a stab at separating the entities and the roles >>>=20 >>> /Dick >>>=20 >>> Tl;dr:=20 >>> - Client -> Grant Client >>> - added Relying Party, Claims Issuer, and Grant Server Operator as = entities >>>=20 >>> Roles - parties to the protocol >>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>=20 >>> Entities - parties to a Trust Framework >>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server = Operator (GSO), Resource Owner (RO) >>>=20 >>> Grant - may contain claims and/or access to resources >>>=20 >>> #Protocol Roles >>>=20 >>> Grant Client (GC) >>> - used by User >>> - operated / provided by RP >>> - requests Grants from the GS >>> - access resources at an RS >>> - consumes Claims >>>=20 >>> Grant Server (GS) >>> - operated by GSO >>> - may interact with the User=20 >>> - may interact with the RO >>> - accepts grant requests from GCs >>> - issues grants to GCs >>> - may issue claims >>>=20 >>> Resource Server (RS) >>> - manages access to resources for the RO >>> - provides access to resources for the GC >>> - accepts access granted by the GS >>>=20 >>> #Legal Entities >>>=20 >>> User >>> - uses Grant Client >>> - may interact with the Grant Server >>> - may also be a RO >>> - trusts RP, Issuer, GSO >>>=20 >>> Relying Party (RP) >>> - provides Grant Client to the User. >>> - may trust Issuers, GSOs, and ROs >>>=20 >>> Claims Issuer (Issuer) >>> - issues claims to RP >>> - may use GS or RS to issue claims >>>=20 >>> Grant Server Operator (GSO) >>> - operates the GS >>> - trusted by User, RP, and RO >>> - may also be an Issuer >>>=20 >>> Resource Owner (RO) >>> - owns resources at the RS >>> - trusts GSO to control access to the resources >>> - may be same entity as the User >>> - may also be an Issuer >>>=20 >>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) = >>>=20 >>> Orchestration (computing) >>> =46rom Wikipedia, the free encyclopedia >>> Jump to navigation >>> = Jump to = search >>> = In = system administration = , orchestration is = the automated configuration = , coordination, = and management of computer systems and software = .[1] = >>> A number of tools exist = for = automation of server configuration and management, including Ansible = , Puppet = , Salt = , Terraform = ,[2] = = and AWS CloudFormation = .[3] = >>> Usage[edit = ] >>> Orchestration is often discussed in the context of service-oriented = architecture = , = virtualization , = provisioning , converged = infrastructure = and dynamic datacenter = topics. Orchestration in this sense is about aligning the business = request with the applications, data, and infrastructure.[4] = >>> In the context of cloud computing = , the main difference = between workflow automation = and orchestration is = that workflows are processed and completed as processes within a single = domain for automation purposes, whereas orchestration includes a = workflow and provides a directed action towards larger goals and = objectives.[1] = >>> In this context, and with the overall aim to achieve specific goals = and objectives (described through quality of service = parameters), for = example, meet application performance goals using minimized cost[5] = and maximize application performance within budget = constraints.[6] = >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones = > = wrote: >>> One of the things that people hated about OAuth was it invented new = terminology that wasn=E2=80=99t in common use. But for better or for = worse, the terms Client, Authorization Server, and Protected Resource = are now widely understood. >>>=20 >>> =20 >>>=20 >>> Let=E2=80=99s not make people similarly hate GNAP by inventing even = more novel terms, when existing terms will fit the bill. Client = wasn=E2=80=99t a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D = to the vocabulary menagerie would definitely make things worse. >>>=20 >>> =20 >>>=20 >>> -- Mike >>>=20 >>> =20 >>>=20 >>> From: TXAuth > On Behalf Of Tom Jones >>> Sent: Tuesday, August 11, 2020 8:44 AM >>> To: Dave Tonge > >>> Cc: Francis Pouatcha >; = Justin Richer >; Dick Hardt = >; Benjamin Kaduk = >; Fabien Imbault = >; Denis = >; txauth@ietf.org = >>> Subject: Re: [GNAP] Terminology >>>=20 >>> =20 >>>=20 >>> the term "orchestator" does not match any use case i have. >>>=20 >>> Let's be clear that there are four entities to a single transaction = in the real world sense of things. (and others that support the = transaction.) >>>=20 >>> Then we can focus on the end point roles. I will focus on the data = privacy issues, API's have the same parties with different terminology. >>>=20 >>> 1. the subject of the data to be transferred. >>>=20 >>> 2. the user of a grant from the subject to act as delegate. (see = https://wiki.idesg.org/wiki/index.php/Delegation = for how to enable the = user) >>>=20 >>> 3. the site that has a repository of user data with legal = obligations to protect that data (the GDPR) (role resource server.) >>>=20 >>> 4 the site that wants either access to the data, or some privacy = preserving statement about the existence and content of the data. (role = of client, vendor, PISP, etc.) >>>=20 >>> 5. some sorts of facilitator sites for allowing access (roles like = authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left out of OAUTH for good reason. >>>=20 >>> =20 >>>=20 >>> This is a note supporting the separation of roles from legal = entities. BTW, I firmly believe that the legal entity also needs to be = ID'd by the transaction. >>>=20 >>> Peace ..tom >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: >>>=20 >>> Hi all >>>=20 >>> =20 >>>=20 >>> I agree that "client" can be confusing. I would be in support of = alternative terminology. >>>=20 >>> We can always have some wording that explains that an "Orchestrator" = in GNAP plays a similar role to "Client" in OAuth. >>>=20 >>> =20 >>>=20 >>> Dave >>>=20 >>> =20 >>>=20 >>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault = > wrote: >>>=20 >>> Hi Francis, >>>=20 >>> =20 >>>=20 >>> I like your proposal, seems much more intuitive.=20 >>>=20 >>> =20 >>>=20 >>> Fabien=20 >>>=20 >>> =20 >>>=20 >>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = > a =C3=A9crit : >>>=20 >>> Hello Denis, Justin, Dick, Fabien, >>>=20 >>> =20 >>>=20 >>> In this post = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ) i suggested we use the word "Orchestrator" to designate the piece of = software that orchestrate interaction between "Requestor" (a.k.a. User), = AS and RS to obtain the protected resource.=20 >>>=20 >>> =20 >>>=20 >>> We are turning around the same topic. As soon as we go beyond the = original oAuth protocol, the word 'Client' becomes confusing. >>>=20 >>> =20 >>>=20 >>> In the same response, I suggest we talk about "roles" and not = "entities". >>>=20 >>> =20 >>>=20 >>> Best regards. >>>=20 >>> /Francis >>>=20 >>> =20 >>>=20 >>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > wrote: >>>=20 >>> I still think that client was the right name in OAuth 2, as the = client wanted to do a client-server interaction, so the client used = OAuth 2 to get an access token to interact with the "server". >>>=20 >>> =20 >>>=20 >>> I do agree that it is not the best term in GNAP. Primarily because = GNAP is a combination of the client from OAuth 2, and the relying party = from OIDC.=20 >>>=20 >>> =20 >>>=20 >>> /Dick >>>=20 >>> =E1=90=A7 >>>=20 >>> =20 >>>=20 >>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > wrote: >>>=20 >>> On Aug 6, 2020, at 12:53 PM, Dick Hardt > wrote: >>>=20 >>> =20 >>>=20 >>> The term client in OAuth came from the computer science definition = of client-server interaction. >>>=20 >>> =20 >>>=20 >>> This, I would argue, is exactly why it=E2=80=99s a bad label for = something that=E2=80=99s distinctly more specific in this context, and I = would love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth. >>>=20 >>> =20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>>=20 >>> The client is getting an access token so it can call a server, = specifically, a resource server (to differentiate it from the = authorization server). >>>=20 >>> =20 >>>=20 >>> The confusion in my experience usually stems from people working = with software that is acting in multiple roles. IE, the software that is = acting as a client in once context, is also acting as an RS in other = contexts, or even acting as an AS. The other confusion is that people = view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =E1=90=A7 >>>=20 >>> =20 >>>=20 >>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault = > wrote: >>>=20 >>> Hi,=20 >>>=20 >>> =20 >>>=20 >>> To me, client has always been a strange word in the context of = OAuth, as it has a meaning well defined both in everyday life (this = client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the = OAuth world before any discussion... And any teaching experience shows = that it does make the concepts hard to grasp for a majority of (clever) = people. >>>=20 >>> =20 >>>=20 >>> As for the RO, previous discussions suggested Resource Controller = (RC) also, which may be a bit more specific than manager.=20 >>>=20 >>> =20 >>>=20 >>> Fabien=20 >>>=20 >>> =20 >>>=20 >>> On Thu, Aug 6, 2020 at 1:00 PM Denis > wrote: >>>=20 >>> Justin and Dick, >>>=20 >>> =20 >>>=20 >>> [Was: "Revisiting the photo sharing example (a driving use case for = the creation of OAuth)"] >>>=20 >>> =20 >>>=20 >>> So let us attempt to define new terms: >>>=20 >>> initiating application (IA): application by means of which a user = initiates interactions with RS(s) and AS(s) >>>=20 >>> In the same way, we should get rid of the term Resource Owner (RO), = which is currently defined as: >>>=20 >>> Resource Owner (RO): entity capable of granting access to a = protected resource >>>=20 >>> I propose to replace it with Resource Manager (RM): >>>=20 >>> Resource Manager (RM) : application or user that manages an access = decision function of a Resource Server >>>=20 >>> Denis >>>=20 >>> =20 >>>=20 >>> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>>=20 >>> =20 >>>=20 >>> Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>>=20 >>> =20 >>>=20 >>> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>>=20 >>> =20 >>>=20 >>> /Dick >>>=20 >>> =E1=90=A7 >>>=20 >>> =20 >>>=20 >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >>>=20 >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>=20 >>> =20 >>>=20 >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>>=20 >>> =20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>=20 >>>=20 >>> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>>=20 >>> =20 >>>=20 >>> I think that is fundamentally part of the question: >>>=20 >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>> confusion >>>=20 >>> =20 >>>=20 >>> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>>=20 >>> =20 >>>=20 >>> Food for thought. >>>=20 >>> - Warren >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Warren Parad >>>=20 >>> Founder, CTO >>>=20 >>> Secure your user data and complete your authorization architecture. = Implement Authress . >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>>=20 >>> Hi Denis, >>>=20 >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> >=20 >>> > Since you replied in parallel, I will make a response similar to = the one=20 >>> > I sent to Dick. >>> >=20 >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >>> > > you describe as RS2, which might in fact be an RS unto itself, = is a=20 >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >>> > > all the same as an OAuth client. I appreciate your mapping of = the=20 >>> > > entities below, but it makes it difficult to hold a discussion = if we=20 >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,=20 >>> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >>> >=20 >>> > In the ISO context, each document must define its own terminology. = The=20 >>> > boiler plate for RFCs does not mandate a terminology or = definitions section >>> > but does not prevent it either. The vocabulary is limited and as = long as=20 >>> > we clearly define what our terms are meaning, we can re-use a term = already >>> > used in another RFC. This is also the ISO approach. >>>=20 >>> Just because we can do something does not necessarily mean that it = is a >>> good idea to do so. We are clear that we are producing a protocol = that is >>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted = Dick to >>> use the term "GS" in XAuth, picking a name that was not already used = in >>> OAuth 2.0. >>>=20 >>> -Ben >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> =20 >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> =20 >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> =20 >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Francis Pouatcha >>>=20 >>> Co-Founder and Technical Lead >>>=20 >>> adorsys GmbH & Co. KG >>>=20 >>> https://adorsys-platform.de/solutions/ = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> =20 >>>=20 >>> =20 >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>=20 >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_34F7C005-21F1-4AC0-A82E-E552B079219C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What = is being granted is access to something. This makes sense in terms of = rights bound to an access token, but I would argue it makes less sense = for things returned directly.

Since you and I also disagree on whether returning things = directly is an important distinction (even though both the XAuth and XYZ = proposals make this distinction), it doesn=E2=80=99t surprise me that = you=E2=80=99d want to extend the notion of =E2=80=9Cgrant=E2=80=9D to = include anything and everything in the request and = response. 

I am arguing for it being more specific and = precise.

 =E2=80=94 Justin

On Aug = 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

A grant is whatever the client is = asking from the server. Currently we have access to resources and = identity claims. It could contain anything else an extension adds that a = client may request from a server.

Given the definition of grant that I included, why is grant = not the right term to use for this?


On Tue, Aug 11, 2020 at 1:35 PM Justin = Richer <jricher@mit.edu> wrote:
I did not say the term =E2=80=9Cgrant=E2=80=9D = was problematic, I said that your definition of it was problematic. = Namely, the desire to lump in claims about the user into the definition = of the =E2=80=9Cgrant=E2=80=9D. 

 =E2=80=94 Justin

On Aug 11, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be = a role in the protocol -- it is not a role in XYZ or XAuth today.

Justin: would you = explain why you think the term "grant" is problematic? It is in the WG = name!

The = client is receiving more than access to resources from the GS, it = is also receiving claims, so "client of the resource" is too = limiting.

Reading the definition of grant[1], it fits as a verb of what = the GS is doing, and fits as a noun of what the GS provides to the = client.

A = Grant Server is an Authorization Server in OAuth, and an OpenID Provider = in OpenID Connect.
The Grant Client is a Client in = OAuth, and a Relying Party in OpenID Connect.

Having new terms (GS and GC) in GNAP, = separating the roles from OAuth and OpenID Connect.
It is straightforward to know what a GC and GS do when = you understand that a grant is a combination of resource access = (from OAuth) and claims (from OpenID Connect).

/Dick

[1] https://www.dictionary.com/browse/grant

verb (used with = object)

to bestow or confer, especially by a formal act:to grant a = charter.
to give or accord:to grant = permission.
to agree or accede to:to grant a = request.
to admit or concede; accept for the sake of argument:I grant that = point.

noun

something granted, as a privilege or right, a sum of money, = or a tract of land:Several major foundations made large = grants to fund the research project.
the act of granting.


[1] 



On Tue, Aug = 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that = =E2=80=9Corchestration=E2=80=9D is separate from what the classical = =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term = =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D = concept that=E2=80=99s been brought up here before, so I=E2=80=99m = inclined to believe it can be a separate role from the client.

I personally think that = =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient= of the grant=E2=80=9D but rather a =E2=80=9Cclient of the = resource=E2=80=9D.

I also think it=E2=80=99s problematic to lump in user claims = with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything. 

 =E2=80=94 Justin

On Aug = 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comments on = preserving names when possible. The shift from "consumer" in OAuth 1 to = "client" in OAuth 2 was confusing to many.

I also echo Tom's = comments about separating Entities from Roles.

Orchestration[1] in my opinion is not = what the "client" is doing.

Below is a stab at separating the entities and the = roles

/Dick

Tl;dr: 
- = Client -> Grant Client
- added Relying = Party, Claims Issuer, and Grant Server Operator as entities

Roles - parties to the protocol
Grant = Client (GC), Grant Server (GS), Resource Server (RS)

Entities - parties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant = Server Operator (GSO), Resource Owner (RO)

Grant - may contain claims and/or = access to resources

#Protocol Roles

Grant Client = (GC)
- used by User
- operated = / provided by RP
- requests Grants from the = GS
- access resources at an RS
-= consumes Claims

Grant Server (GS)
- = operated by GSO
- may interact with the = User 
- may interact with the RO
- accepts grant requests from GCs
- = issues grants to GCs
- may issue claims

Resource = Server (RS)
- manages access to resources for = the RO
- provides access to resources for the = GC
- accepts access granted by the GS

#Legal = Entities

User
- uses Grant Client
- may interact with the Grant Server
- = may also be a RO
- trusts RP, Issuer, GSO

Relying = Party (RP)
- provides Grant Client to the User. =
- may trust Issuers, GSOs, and ROs

Claims = Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant Server Operator = (GSO)
- operates the GS
- = trusted by User, RP, and RO
- may also be an = Issuer

Resource Owner (RO)
- = owns resources at the RS
- trusts GSO to control = access to the resources
- may be same entity as the = User
- may also be an = Issuer

[1] https://en.wikipedia.org/wiki/Orchestration_(computing)

Orchestration (computing)

=46rom Wikipedia, the free = encyclopedia
Jump to navigationJump to search
In system administration, orchestration is the automated configuration, coordination, and = management of computer systems and software.[1]
A number of tools exist for = automation of server configuration and management, including Ansible, Puppet, Salt, Terraform,[2] and AWS CloudFormation.[3]

Usage[edit]

Orchestration is often discussed in the context of service-oriented architecture, virtualization, provisioning, converged infrastructure and = dynamic datacenter topics. Orchestration = in this sense is about aligning the business request with the = applications, data, and infrastructure.[4]
In the context of cloud computing, the main difference = between workflow automation and = orchestration is that workflows are processed and completed as processes = within a single domain for automation purposes, whereas orchestration = includes a workflow and provides a directed action towards larger goals = and objectives.[1]
In this context, and with the overall aim to achieve = specific goals and objectives (described through quality of service parameters), = for example, meet application performance goals using minimized cost[5] and maximize application = performance within budget constraints.[6]








On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the things that people hated about OAuth was it = invented new terminology that wasn=E2=80=99t in common use.  But = for better or for worse, the terms Client, Authorization Server, and = Protected Resource are now widely understood.

 

Let=E2=80= =99s not make people similarly hate GNAP by inventing even more novel = terms, when existing terms will fit the bill.  Client wasn=E2=80=99t = a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the = vocabulary menagerie would definitely make things worse.

 

          &nb= sp;   =             &n= bsp;           &nbs= p;            =     -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

 

the term "orchestator" does not = match any use case i have.

Let's be clear that there are = four entities to a single transaction in the real world sense of things. = (and others that support the  transaction.)

Then we can focus on the end = point roles. I will focus on the data privacy issues, API's have the = same parties with different terminology.

1. the subject of the data to be = transferred.

2. the user of a grant from the = subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how = to enable the user)

3. the site that has a repository = of user data with legal obligations to protect that data (the GDPR) = (role resource server.)

4 the site that wants either = access to the data, or some privacy preserving statement about the = existence and content of the data. (role of client, vendor, PISP, = etc.)

5. some sorts of facilitator = sites for allowing access (roles like authenticator, idp, verifier, csp, = RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

 

This is a note supporting the = separation of roles from legal entities.  BTW, I firmly believe = that the legal entity also needs to be ID'd by the transaction.

Peace ..tom

 

 

On Tue, Aug 11, 2020 at 1:42 AM = Dave Tonge <dave.tonge@moneyhub.com> wrote:

Hi = all

 

I = agree that "client" can be confusing. I would be in support of = alternative terminology.

We = can always have some wording that explains that an "Orchestrator" in = GNAP plays a similar role to "Client" in OAuth.

 

Dave

 

On Tue, 11 Aug 2020 at 07:52, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Francis,

 

I like your proposal, seems much = more intuitive. 

 

Fabien 

 

Le mar. 11 ao=C3=BBt 2020 =C3=A0 = 04:17, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit :

Hello Denis, Justin, Dick, = Fabien,

 

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between = "Requestor" (a.k.a. User), AS and RS to obtain the protected = resource. 

 

We are turning around the same = topic. As soon as we go beyond the original oAuth protocol, the = word 'Client' becomes confusing.

 

In the same response, I = suggest we talk about "roles" and not "entities".

 

Best regards.

/Francis

 

On Thu, Aug 6, 2020 at 6:36 PM = Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the = right name in OAuth 2, as the client wanted to do a client-server = interaction, so the client used OAuth 2 to get an access token to = interact with the "server".

 

I do agree that it is not the = best term in GNAP. Primarily because GNAP is a combination of the client = from OAuth 2, and the relying party from OIDC. 

 

/Dick

=E1=90=A7

 

On Thu, Aug 6, 2020 at 12:50 PM = Justin Richer <jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

 

The term client in OAuth came = from the computer science definition of client-server interaction.

 

This, I would argue, is exactly = why it=E2=80=99s a bad label for something that=E2=80=99s distinctly = more specific in this context, and I would love to see GNAP adopt a more = specific label for the role that we traditionally called =E2=80=9Cclient=E2= =80=9D in OAuth.

 

 =E2=80=94 Justin



 

The client is getting an access = token so it can call a server, specifically, a resource server (to = differentiate it from the authorization server).

 

The confusion in my experience = usually stems from people working with software that is acting = in multiple roles. IE, the software that is acting as a client = in once context, is also acting as an RS in other contexts, or even = acting as an AS. The other confusion is that people view clients as being the = software the user is using -- although it may not be acting as a client = in the oauth context.

 

 

 

=E1=90=A7

 

On Thu, Aug 6, 2020 at 4:49 AM = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

 

To me, client has always been a = strange word in the context of OAuth, as it has a meaning well defined = both in everyday life (this client is a good customer) and in computer = science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And = any teaching experience shows that it does make the concepts hard to = grasp for a majority of (clever) people.

 

As for the RO, previous = discussions suggested Resource Controller (RC) also, which may = be a bit more specific than manager. 

 

Fabien 

 

On Thu, Aug 6, 2020 at 1:00 PM = Denis <denis.ietf@free.fr> wrote:

Justin and = Dick,

 

[Was:  = "Revisiting the photo sharing example (a driving use case for the = creation of OAuth)"]

 

So let us attempt to = define new terms:

initiating application = (IA): = application by means of which a user initiates interactions with RS(s) = and AS(s)

In the same way, we = should get rid of the term Resource Owner (RO), which is currently = defined as:

Resource Owner (RO): = entity capable of granting access to a protected resource

I propose to replace = it with Resource Manager (RM):

Resource Manager = (RM) = : application or user that manages an access decision function of a = Resource Server

Denis

 

I agree with Justin. Redefining = well used terms will lead to significant confusion. If we have a = different role than what we have had in the past, then that role = should have a name not being used already in OAuth or OIDC.

 

Given what we have learned, and = my own experience explaining what a Client is, and is not, improving the = definition for Client could prove useful. I am not suggesting the term = be redefined, but clarified. 

=

 

For example, clarifying that a = Client is a role an entity plays in the protocol, and that the same = entity may play other roles at other times, or some other language to = help differentiate between "role" and "entity".

 

/Dick

=E1=90=A7

 

On Wed, Aug 5, 2020 at 8:20 AM = Justin Richer <jricher@mit.edu> wrote:

I=E2=80=99m in favor of coming up = with a new term that=E2=80=99s a better fit, but I=E2=80=99m not really = in favor of taking an existing term and applying a completely new = definition to it. In other words, I would sooner stop using =E2=80=9Cclien= t=E2=80=9D and come up with a new, more specific and accurate term for the role than to define = =E2=80=9Cclient=E2=80=9D as meaning something completely different. We = did this in going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizat= ion Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

 

GNAP can do something similar, in = my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is = going to be coming up in a world that is already permeated  by = OAuth 2 and its terminology. We don=E2=80=99t have a blank slate to work = with, but neither are we bound to use the same terms and constructs as before. = It=E2=80=99s going to be a delicate balance!

 

 =E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, = Warren Parad <wparad@rhosys.ch> wrote:

 

I think that is fundamentally = part of the question:

We are clear that we are producing a protocol that = is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

 

If we say that this document = assumes OAuth2.0 terminology, then we should not change the meanings of = any definition. If we are saying this supersedes or replaces what OAuth = 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand = experience of industries "ruining words", and attempting to side-step = the problem rather than redefining the word just confuses everyone as = everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious = word continues.

 

Food for thought.

- Warren

Warren = Parad

Founder, = CTO

Secure your user data and complete your authorization = architecture. Implement Authress.

 

 

On Tue, Aug 4, 2020 at 8:53 PM = Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

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

 

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

 

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

 

--
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/

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

 

 

Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number 06909772. = Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject = to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are = made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's = business. Any opinions expressed in this email (or in any attachments) = are those of the author and do not necessarily represent the opinions of = Moneyhub Financial Technology Limited or of any other group company.


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




= --Apple-Mail=_34F7C005-21F1-4AC0-A82E-E552B079219C-- From nobody Wed Aug 12 09:02:36 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 6AF503A1386 for ; Wed, 12 Aug 2020 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 raucCWHV4PXf for ; Wed, 12 Aug 2020 09:02:32 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212193A1383 for ; Wed, 12 Aug 2020 09:02:30 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d09 with ME id Eg2T230062bcEcA03g2TXG; Wed, 12 Aug 2020 18:02:29 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 12 Aug 2020 18:02:29 +0200 X-ME-IP: 90.79.51.120 To: Justin Richer Cc: Benjamin Kaduk , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> From: Denis Message-ID: Date: Wed, 12 Aug 2020 18:02:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> Content-Type: multipart/alternative; boundary="------------08F78B7D4CB9C11530E22F91" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 16:02:36 -0000 This is a multi-part message in MIME format. --------------08F78B7D4CB9C11530E22F91 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, A soon as the RS needs to talk to the GS (step 2a) , it is a "Big Brother by Design" architecture. Do you want to mandate it ? Denis > +1 to this. I think that the core protocol needs to be designed to > allow this kind of action, but I also think it is possible that the > details of this could end up in an extension to the main document. > I’ve put a flag in the ground for this in XYZ in sections 10.3 and > 10.4, which is adapted from UMA2’s distributed authorization protocol: > > https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.3 > > The important detail here, in XYZ’s design, is that the RS has a clear > way to communicate to the client what will be needed to fulfill the > request, and the client/orchestrator/whatever has a clear way to > incorporate that into the main protocol. The details of (2) using the > XYZ pattern are: > > +-----------+ +--------------+  +----+  +----+  +---------------------+ > | Requestor |      | Orchestrator |  |    |  | GS |  | Resource > Controller | > |   was     | |     was      |  | RS |  | or |  |         was         | > |  User     | |   Client     |  |    |  | AS |  |    Resource Owner   | > +-----------+      +--------------+  +----+  +----+ >  +---------------------+ >   |(1) ServiceRequest     |            |       |     | >   |---------------------->|            |       |       | >   |                       |(2) ServiceIntent:AuthZChallenge    | >   |                       |----------->|       |       | >   |         |            |       |                | >   |         |            |(2a) Register resource set > |                       |            |------>|     | >   |            |            |       |                | >   |            |            |(2b) Return resource reference handle >   |            |            |<------|                | >   |            |            |       |                | >   |            |(2c) Return AS URL and resource reference handle >   |            |<-----------|       |                | >   |            |            |       |                | >   |                       |(3) AuthZRequest(AuthZChallenge, include > resource handle) >   |                       |------------------->|       | > > > Note that the client can ALSO request additional resources on top of > what the RS returned in (2b), since this is passed simply as one > element of the array. > >  — Justin > >> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha > > wrote: >> >> Hello Dick, >> >> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt > > wrote: >> >> Hi Francis >> >> The user is an entity, not a role in the protocol in how I am >> defining roles, so steps (1) and (7) are confusing to me on what >> is happening. >> >> "Requestor" is the role (*was* User). So the UML participant >> refers to the role "Requestor" >> >> >> I also think that (2) could be an extension to GNAP, rather than >> part of the core protocol. >> >> If you make it an extension, you hide. It shall rather be an >> optional, integral part of the protocol. If the >> "Orchestrator/Negotiator/Client" can translate the service request >> into a resource request, then there will be no need to invoke (2). >> >> When we move beyond identity management, cases become complex and it >> makes sense to explicitly display this possibility in the protocol flow. >> >> In some open banking designs, >> - the "Orchestrator/Negotiator/Client" will not know the AS to talk >> to unless the call (2). >> - the request (2) might result in an exemption, meaning no need for >> further authorization, allowing to skip (3, 4, 5) and even (6). >> >> /Francis >> >> >> >> >> >> >> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha > > wrote: >> >> In this context, I suggest we pick some words to work with, >> and sharpen them as we move on, discover and map new use >> cases to the protocol. >> >> In this diagram from the original thread >> (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), >> I replaced the words: >> >> +-----------+     +--------------+  +----+  +----+ >>  +---------------------+ >> | Requestor |      | Orchestrator |  | |  | GS |  | Resource >> Controller | >> |  was     |      |     was      |  | RS | | or |  |        >>  was         | >> | User     |      |   Client     |  |    | | AS |  |    >> Resource Owner   | >> +-----------+      +--------------+  +----+  +----+ >>  +---------------------+ >>   |(1) ServiceRequest     |            |      |                | >>   |---------------------->| |       |                | >>   |                       |(2) ServiceIntent:AuthZChallenge     | >>   |  |<---------->|       |   | >>   |                       |            |      |                | >>   |                       |(3) AuthZRequest(AuthZChallenge)     | >>   |  |------------------->| | >>   |                       |            |      |(4) >> ConsentRequest:Grant >>   |                       |            |      |<-------------->| >>   |                       |(5) GrantAccess(AuthZ)               | >>   |  |<-------------------| | >>   |                       |            |      |                | >>   |                       |(6) >> ServiceRequest(AuthZ):ServiceResponse >>   |  |<---------->|       |   | >>   |(7) ServiceResponse    |            |      |                | >>   |<----------------------| |       |                | >>   +                       +            +      +                + >> >> The purpose of the GNAP protocol is to help negotiate access >> to a protected resource. It starts with a requestor >> delegating activity to an orchestrator. These are all roles, >> no entities. Let focus on mapping the use cases to the >> protocol roles and interactions so wwe can discover what is >> missing. >> >> It seems cumbersome to use it in discussions as it is >> impossible to give the word "Client" a clear definition. >> >> We can mention in the final document, that the "Orchestrator" >> (or whatever word we finally use) plays the same role as the >> "Client" in oAuth2. >> >> Best regards. >> /Francis >> >> >> >> >> >> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >> > wrote: >> >> I agree with Justin. Redefining well used terms will lead >> to significant confusion. If we have a different role >> than what we have had in the past, then that role should >> have a name not being used already in OAuth or OIDC. >> >> Given what we have learned, and my own experience >> explaining what a Client is, and is not, improving the >> definition for Client could prove useful. I am not >> suggesting the term be redefined, but clarified. >> >> For example, clarifying that a Client is a role an entity >> plays in the protocol, and that the same entity may play >> other roles at other times, or some other language to >> help differentiate between "role" and "entity". >> >> /Dick >> ᐧ >> >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >> > wrote: >> >> I’m in favor of coming up with a new term that’s a >> better fit, but I’m not really in favor of taking an >> existing term and applying a completely new >> definition to it. In other words, I would sooner stop >> using “client” and come up with a new, more specific >> and accurate term for the role than to define >> “client” as meaning something completely different. >> We did this in going from OAuth 1 to OAuth 2 already, >> moving from the even-more-confusing “consumer” to >> “client”, but OAuth 2 doesn’t use the term “consumer” >> at all, nor does it use “server” on its own but >> instead always qualifies it with “Authorization >> Server” and “Resource Server”. >> >> GNAP can do something similar, in my opinion. But >> what we can’t do is ignore the fact that GNAP is >> going to be coming up in a world that is already >> permeated  by OAuth 2 and its terminology. We don’t >> have a blank slate to work with, but neither are we >> bound to use the same terms and constructs as before. >> It’s going to be a delicate balance! >> >>  — Justin >> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>> > wrote: >>> >>> I think that is fundamentally part of the question: >>> >>> We are clear that we are producing a protocol >>> that is >>> conceptually (if not more strongly) related to >>> OAuth 2.0, and reusing terms >>> from OAuth 2.0 but with different definitions >>> may lead to unnecessary >>> confusion >>> >>> >>> If we say that this document assumes OAuth2.0 >>> terminology, then we should not change the meanings >>> of any definition. If we are saying this supersedes >>> or replaces what OAuth 2.0 creates, then we should >>> pick the best word for the job and ignore >>> conflicting meanings from OAuth 2.0. I have a lot of >>> first hand experience of industries "ruining words", >>> and attempting to side-step the problem rather than >>> redefining the word just confuses everyone as >>> everyone forgets the original meaning as new >>> documents come out, but the confusion with the use >>> of a non-obvious word continues. >>> >>> Food for thought. >>> - Warren >>> >>> >>> Warren Parad >>> Founder, CTO >>> >>> Secure your user data and complete your >>> authorization architecture. Implement Authress >>> . >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>> > wrote: >>> >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis >>> wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a >>> response similar to the one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there’s still a problem with the >>> terminology in use here. What >>> > > you describe as RS2, which might in fact be >>> an RS unto itself, is a >>> > > “Client” in OAuth parlance because it is /a >>> client of RS1/. What you >>> > > call a “client” has no analogue in the OAuth >>> world, but it is not at >>> > > all the same as an OAuth client. I >>> appreciate your mapping of the >>> > > entities below, but it makes it difficult to >>> hold a discussion if we >>> > > aren’t using the same terms. >>> > > >>> > > The good news is that this isn’t OAuth, and >>> as a new WG we can define >>> > > our own terms. The bad news is that this is >>> really hard to do. >>> > > >>> > > In GNAP, we shouldn’t just re-use existing >>> terms with new definitions, >>> > > but we’ve got a chance to be more precise >>> with how we define things. >>> > >>> > In the ISO context, each document must define >>> its own terminology. The >>> > boiler plate for RFCs does not mandate a >>> terminology or definitions section >>> > but does not prevent it either. The vocabulary >>> is limited and as long as >>> > we clearly define what our terms are meaning, >>> we can re-use a term already >>> > used in another RFC. This is also the ISO >>> approach. >>> >>> Just because we can do something does not >>> necessarily mean that it is a >>> good idea to do so.  We are clear that we are >>> producing a protocol that is >>> conceptually (if not more strongly) related to >>> OAuth 2.0, and reusing terms >>> from OAuth 2.0 but with different definitions >>> may lead to unnecessary >>> confusion.  If I understand correctly, a similar >>> reasoning prompted Dick to >>> use the term "GS" in XAuth, picking a name that >>> was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> 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/ > --------------08F78B7D4CB9C11530E22F91 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Justin,

A soon as the RS needs to talk to the GS (step 2a) , it is a "Big Brother by Design" architecture.
Do you want to mandate it ?

Denis

+1 to this. I think that the core protocol needs to be designed to allow this kind of action, but I also think it is possible that the details of this could end up in an extension to the main document. I’ve put a flag in the ground for this in XYZ in sections 10.3 and 10.4, which is adapted from UMA2’s distributed authorization protocol:


The important detail here, in XYZ’s design, is that the RS has a clear way to communicate to the client what will be needed to fulfill the request, and the client/orchestrator/whatever has a clear way to incorporate that into the main protocol. The details of (2) using the XYZ pattern are:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |----------->|       |                |
  |                       |            |       |                |
  |                       |            |(2a) Register resource set
  |                       |            |------>|                |
  |                       |            |       |                |
  |                       |            |(2b) Return resource reference handle
  |                       |            |<------|                |
  |                       |            |       |                |
  |                       |(2c) Return AS URL and resource reference handle
  |                       |<-----------|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge, include resource handle)
  |                       |------------------->|                |


Note that the client can ALSO request additional resources on top of what the RS returned in (2b), since this is passed simply as one element of the array. 

 — Justin

On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <fpo@adorsys.de> wrote:

Hello Dick,

On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). So the UML participant refers to the role "Requestor"


I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol. If the "Orchestrator/Negotiator/Client" can translate the service request into a resource request, then there will be no need to invoke (2).

When we move beyond identity management, cases become complex and it makes sense to explicitly display this possibility in the protocol flow.

In some open banking designs, 
- the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2).
- the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

/Francis





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

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

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
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


--------------08F78B7D4CB9C11530E22F91-- From nobody Wed Aug 12 09:05:19 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 0E8913A120C for ; Wed, 12 Aug 2020 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qduW6-_D38ON for ; Wed, 12 Aug 2020 09:05:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C75A3A1156 for ; Wed, 12 Aug 2020 09:05:15 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CG5Cp8024691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 12:05:13 -0400 From: Justin Richer Message-Id: <824C513A-65F8-4D86-BE1C-4885A1B4D289@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_C43FB935-AE6E-424B-A0B5-FBDAD95C3493" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 12:05:12 -0400 In-Reply-To: Cc: Yaron Sheffer , GNAP Mailing List To: Francis Pouatcha References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> <5B49BD4E-9EE5-4B8B-A24C-981E579726A9@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Design team formed 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: Wed, 12 Aug 2020 16:05:18 -0000 --Apple-Mail=_C43FB935-AE6E-424B-A0B5-FBDAD95C3493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The goal of the design team is to take a step aside from the public = mailing list and, hopefully, get more done in a short time period. = Discussion on a public mailing list is powerful, but slow and prone to = derailing and miscommunication. The design team will discuss things more = directly to avoid those problems in the short term, much the way that a = small subcommittee can bring targeted expertise to a group=E2=80=99s = problem by using higher bandwidth communication channels and regular = interaction. The results will be brought back to the list to be = discussed and, hopefully, adopted as a starting point. That starting = point document will then be debated, edited, and refined by the working = group. Nothing in the starting document is sacred, but at least it will = be something concrete to build on. While the design team is working, discussion will continue on the list, = and all the design team members are still participating on the list. = This ongoing conversation is still very valuable for the group as a = whole, including the design team, even if it=E2=80=99s not a direct feed = of the design team=E2=80=99s discussions.=20 There are a LOT of amazing people in this group =E2=80=94 I see that as = a testament to how important this problem space is and how much of an = appetite there is for solving things in that space. This process is = going to take a while, maybe years of debate and engineering before we = reach a final standard. There is going to be a lot of opportunity to = contribute, and I look forward to your continuing contributions. The IETF has this writeup on the nature and utility of design teams, = which you might find useful: = https://www.ietf.org/about/groups/iesg/statements/design-teams/ = =E2=80=94 Justin > On Aug 12, 2020, at 11:31 AM, Francis Pouatcha wrote: >=20 > Justin, >=20 > Thanks for your response. I hope the design team will keep addressing = essential topics on the list so we can contribute. >=20 > Best regards. > /Francis >=20 > On Wed, Aug 12, 2020 at 11:24 AM Justin Richer > wrote: > Francis, >=20 > The design team is just a temporary construct to get things started = here, and it will dissolve back into the WG when the task is over. I, = for one, am really thankful to have you bring your experience to this = working group. I=E2=80=99ve appreciated your contributions greatly so = far, and I look forward to continuing to work with you. >=20 > We still have a long way to go and a lot of work to do. The output of = the design team is just the start of the working group, and there are = many more things to figure out. >=20 > =E2=80=94 Justin >=20 >> On Aug 11, 2020, at 1:25 PM, Francis Pouatcha = > wrote: >>=20 >> It is unfortunate I didn't make it. Would have liked to bring in my = 22 years of experience in building authz applications. >>=20 >> Best regards. >> /Francis >>=20 >> On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer > wrote: >> Thank you all for attending the inaugural GNAP meeting at IETF-108. = We had quite a few volunteers, and the chairs picked the following = people for the design team: >>=20 >> * Kathleen Moriarty >> * Justin Richer >> * Dick Hardt >> * Mike Jones >> * Fabien Imbault >>=20 >> Kathleen has graciously agreed to convene the sessions and report on = the team's outcome. Thank you all who volunteered! >>=20 >> We expect the design team to decide on a solution outline that = combines the best of both proposals, and present this outline by Sep. = 15. Anything is as usual subject to approval by the whole working group. >>=20 >> Thanks, >> Leif and Yaron >>=20 >>=20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> Francis Pouatcha >> Co-Founder and Technical Lead >> adorsys GmbH & Co. KG >> https://adorsys-platform.de/solutions/ = --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ = --Apple-Mail=_C43FB935-AE6E-424B-A0B5-FBDAD95C3493 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = goal of the design team is to take a step aside from the public mailing = list and, hopefully, get more done in a short time period. Discussion on = a public mailing list is powerful, but slow and prone to derailing and = miscommunication. The design team will discuss things more directly to = avoid those problems in the short term, much the way that a small = subcommittee can bring targeted expertise to a group=E2=80=99s problem = by using higher bandwidth communication channels and regular = interaction. The results will be brought back to the list to be = discussed and, hopefully, adopted as a starting point. That starting = point document will then be debated, edited, and refined by the working = group. Nothing in the starting document is sacred, but at least it will = be something concrete to build on.

While the design team is working, = discussion will continue on the list, and all the design team members = are still participating on the list. This ongoing conversation is still = very valuable for the group as a whole, including the design team, even = if it=E2=80=99s not a direct feed of the design team=E2=80=99s = discussions. 

There are a LOT of amazing people in this group =E2=80=94 I = see that as a testament to how important this problem space is and how = much of an appetite there is for solving things in that space. This = process is going to take a while, maybe years of debate and engineering = before we reach a final standard. There is going to be a lot of = opportunity to contribute, and I look forward to your continuing = contributions.

The IETF has this writeup on the nature and utility of design = teams, which you might find useful: https://www.ietf.org/about/groups/iesg/statements/design-teams/=


 =E2=80=94 Justin

On Aug 12, 2020, at 11:31 AM, Francis Pouatcha <fpo@adorsys.de> = wrote:

Justin,

Thanks for your response. I hope = the design team will keep addressing essential topics on the list so we = can contribute.

Best regards.
/Francis

On Wed, Aug 12, 2020 at 11:24 AM Justin Richer = <jricher@mit.edu> = wrote:
Francis,

The design team is just a temporary construct to get things = started here, and it will dissolve back into the WG when the task is = over. I, for one, am really thankful to have you bring your experience = to this working group. I=E2=80=99ve appreciated your contributions = greatly so far, and I look forward to continuing to work with = you.

We still = have a long way to go and a lot of work to do. The output of the design = team is just the start of the working group, and there are many more = things to figure out.

 =E2=80=94 Justin

On Aug = 11, 2020, at 1:25 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

It is unfortunate = I didn't make it. Would have liked to bring in my 22 years of experience = in building authz applications.

Best regards.
/Francis

On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:
Thank you all for attending the = inaugural GNAP meeting at IETF-108. We had quite a few volunteers, and = the chairs picked the following people for the design team:
=
* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the = team's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines = the best of both proposals, and present this outline by Sep. 15. = Anything is as usual subject to approval by the whole working group.

Thanks,
        Leif and Yaron



--
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/
--
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/

= --Apple-Mail=_C43FB935-AE6E-424B-A0B5-FBDAD95C3493-- From nobody Wed Aug 12 09:07:49 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 091633A13A3 for ; Wed, 12 Aug 2020 09:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HrKg3m_ML5By for ; Wed, 12 Aug 2020 09:07:45 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCDA3A13A0 for ; Wed, 12 Aug 2020 09:07:44 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CG7cgN025728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 12:07:38 -0400 From: Justin Richer Message-Id: <319DAB20-198D-48B7-B0B8-72881D234633@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2EEF5A1C-9671-4E6D-86F3-ED2AF404E3D1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 12:07:37 -0400 In-Reply-To: Cc: Fabien Imbault , Francis Pouatcha , GNAP Mailing List To: Denis References: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 16:07:48 -0000 --Apple-Mail=_2EEF5A1C-9671-4E6D-86F3-ED2AF404E3D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Denis, I think this is a fascinating approach that can allow for = privacy-preservation in the way that you=E2=80=99re after. Here=E2=80=99s = how I would see it fitting into GNAP: When the client makes the request, it includes the = concealed_target_identifer in the resources request, probably in lieu of = any kind of =E2=80=9Clocation=E2=80=9D field. The semantics of this = field could be defined in GNAP core or in a short extension describing = the reusable field in the =E2=80=9Cresources=E2=80=9D request: resources: [ =E2=80=9Caction": [=E2=80=9Cread=E2=80=9D], =E2=80=9Cconcealed_target_identifier=E2=80=9D: = =E2=80=9C876tghjkjasdf7234f=E2=80=9D ] At that point, it=E2=80=99s up to the AS to bind that identifier to the = resulting access token and make that information available to the RS. = That could happen by packing it into a JWT, which is likely the format = you=E2=80=99d want for this kind of thing because an introspection call = from the RS would identify the RS to the AS.=20 The missing piece is a way for the client to present the random number = to the RS alongside the access token. I think this would make sense as a = separate HTTP header defined in that extension. So the client would get = back its token and send this to the RS: Authorization: GNAP eyj0=E2=80=A6 Target-Identifier-Random-Number: ABE54298411... The RS would look at the token, find the hashed value within, and use = the value in the secondary header to recalculate and verify the hash on = the request. All of this can be done without the RS calling the AS and = without the client divulging the RS=E2=80=99s location or identity to = the AS. =E2=80=94 Justin > On Aug 12, 2020, at 10:34 AM, Denis wrote: >=20 > Hi Fabien, >> Thanks Denis. >>=20 >> A few questions to clarify:=20 >> - "the field included into the access token will look like a random = number to the RS." - you mean AS? > Correct. This was a typo. >=20 >> - "It should have two parts : a signed part and an unsigned part." - = Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping = (with short expiry) between the temporary_id and the url, on the RS = side? > Sorry, I am not aware of this scheme. >=20 >> Then the algorithm would be : >> 1. Client contacts the RS, which sends a resource description = (temporary_id) > No. It is not a temporary_id. =20 >=20 >> 2. The flow continues and a token is generated, using the = temporary_id. > No. Knowing the true identifier of the RS, the Client picks a = random_number and computes a concealed_target_identifier =3D hash = (random_number, RS_identifier). >=20 > While requesting an access token, the Client asks the AS to include = the concealed_target_identifier into the access token. >=20 > While sending the access token, the Client adds the random_number into = the unsigned part of the access token. >=20 > While receiving the access token, the RS uses it own RS_identifier and = retrieves the random_number placed into the unsigned part of the access = token. > It then computes a hash of (random_number, RS_identifier). If the = result matches with the concealed_target_identifier placed into the = signed part of=20 > the access token, then the access token is well targeted, otherwise it = is ignored. >=20 >> 3. Client makes the call to the RS, using the token. The RS verifies = the signature + it also verifies that the mapping is the one expected. =20= >>=20 >> BTW, it makes the RS decide the maximum token expiry. > Token expiration is unrelated. >=20 >> The issue is that it requires more work on the RS side, compared to a = stateless JWT.=20 > Adding two computations using a one way hash function is not a big = deal. >=20 >> Is that correct? > No. The mechanism is fairly different. It has already been explained = once on the OAuth mailing list. >=20 > Denis >=20 >>=20 >> Fabien >>=20 >>=20 >> On Wed, Aug 12, 2020 at 3:24 PM Denis > wrote: >> With so many messages in the last 24 hours, I can't respond to all of = them at once. >> I picked the last one first. >>=20 >>> Inline too :-) >>>=20 >>> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha > wrote: >>> Hello Fabian, inline >>>=20 >>> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault = > wrote: >>> Hi Francis,=20 >>>=20 >>> My comments are embedded into your email with FI. >>>=20 >>> You're saying in a follow-up message:=20 >>> "- If you want privacy, don't expose RS identity to AS. >>> - If you want transparency, expose RS identity to AS. >>> You can't have both...." >>> While that may seem a reasonable dichotomy at first sight, I believe = the reality is actually more nuanced and depends on how we end up = designing the system.=20 >> [Denis] This is in fact more nuanced. It is possible to prevent the = AS to know who the RS is by hiding the true identifier of the RS to the = AS. >>=20 >> This means that for security reasons the access token is still = targeted but that the field included into the access token will look = like a random number to the RS. >> That random number will change for every access token. >>=20 >> In order for the RS to make sure that the access token is indeed = intended for itself, it will need to combine the field included into the = access token=20 >> with an unsigned field external to the access token.=20 >>=20 >> This would have a major consequence for the structure of a GNAP = access token that will be rather different from an OAuth 2.0 access = token.=20 >> It should have two parts : a signed part and an unsigned part. >>=20 >>>=20 >>> Cheers, >>> Fabien >>>=20 >>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha > wrote: >>> Hello Fabian, >>>=20 >>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault = > wrote: >>> Hi Francis, >>>=20 >>> I think Denis points to the fact that, in the current situation, the = AS receives the resource request from the Client and therefore knows = what tokens are asked. >>> The token request must not mention any reference of the RS. >>>=20 >>> FI : yes we can do that, but as Tom commented, it's not a general = rule. And for instance in XYZ you do describe the URL of the resource. = See also the use case on directed tokens, which is an interesting topic = which makes sense in many scenarios. =20 >>> Yes. But disclosing the protected resource discloses the RS.=20 >>>=20 >>> FI : yes of course. Which is why RS hiding may be a solution.=20 >>>=20 >>> But as soon as you include that possibility, it's fair to think that = this capability could be used for surveillance purposes in some cases, = unless you found a privacy by design scheme that applies by default.=20 >>> Yes. THen default shall be using URI of resource description and not = URL to indicate resource location.=20 >>>=20 >>> FI : yes=20 >>>=20 >>> Again this doesn't mean that transparency requirements aren't = important too, but I think there are other ways it can be achieved (for = instance, an inspiration is the certificate transparency project). Could = be an extension to the protocol I believe.=20 >>> The certificate transparency deals with something else. Does not fit = in this context at all. >>> =20 >>> FI : It does, and has already been implemented by some projects in = relationship with OAuth2, as an additional component.=20 >>>=20 >>> =20 >>> Then it also implements the consent interface (and possibly the = login too) and so it also knows who validates and what is accepted or = not. >>> Decoupling this does not change the privacy context, as the AS = issues the Token. AS needs to add a reference to the RC in the token. SO = AS can correlate on StudentId anyway. >>>=20 >>> FI : I disagree. It does change the privacy context, if as Denis = suggested, the consent is made outside of the AS and if you don't send = to the AS the information on the RS when it needs to issue the token. >>> Correlation on StudentId is limited as long as it's a local = identifier, i.e. not a public DID.=20 >>> How local can the StudentId be? It is known to both universities and = to the AS. Without a public reference, you can not link information = between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help = here. Then you do not need central AS anymore. >>>=20 >>> FI : see keri or peer DID for instance, as examples of local ID.=20 >>> Again SSI/DID/VC doesn't mean you don't need AS, those technologies = can be complementary.=20 >>> =20 >>>=20 >>> As a concrete example: a user may want to use an application to = access rs_domain/directory1 and rs_domain/directory2 in read and write, = which are managed by a RO.=20 >>> What I suggested is that the Client may (optionally) carry out its = consent through a decoupled IS server (separated from the AS), that = displays the UI based on the RS requirements =3D> the IS knows what = information is used, but the IS may be chosen by the IS independently = from the AS or even run by the Client itself.=20 >>> What do you need an AS for? Then it can sign the claim to present to = RS. >>>=20 >>> FI : to be sure, what is "it"?=20 >>> =20 >>> =20 >>> In this case, suppose the RO only provided consent for = rs_domain/directory1 for read.=20 >>> We now need to get back to the AS to mint the access token.=20 >>> If AS mint access token, AS will be able to correlate. Unless start = applying intransparent complex reference mapping techniques, wich might = even open room for new attack vectors. >>>=20 >>> FI : not necessarily with respect to correlation, see above. >>> As for mapping techniques, this is the very reason of my question to = Denis.=20 >>>=20 >>>=20 >>> If we want the AS to not know about the RS, we either :=20 >>> - don't supply the rs_domain at all -> the JWT says that directory1 = in read access is authorized. The downside is that we actually cannot = control to which URL the authorization applies. In that case I agree = with your either or statement. =20 >>> Yes=20 >>> - or find a way to hide it (not sure if that's practical, hence my = questions on RS hiding). This would have the benefit of still allowing = directed tokens -> the JWT says that rs_petname/directory1 in read = access is authorized. >>> More complexity.=20 >>>=20 >>> FI : yes >> [Denis] As indicated at the top of this email, it is possible to = always hide the identifier of the RS while still targetting every access = token. >>=20 >> BTW, I have expanded the notion of targetting by allowing to place = into a target field of an access token either or both a RS identifier = and=20 >> a Service Name (SN) identifier to which the RS belongs. >>=20 >> Two targetting fields should hence be possible: a RS identifier and a = SN identifier. >>=20 >> This is also a difference with an OAuth 2.0 access token. >>=20 >>> Either way, the AS has not been provided any information as to where = this token will effectively be used. =20 >>>=20 >>>=20 >>> I don't think the abstract flow deals with those privacy concerns.=20= >>> To solve the privacy problem addressed in this thread, we need to go = the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue = a VC (Verifiable Credential) to the Student (in his role of RC). The = Student will then present this claim to UNIV-1 during his registration. = In this case we need no Grant negotiation and no AS. >> [Denis] This is a complete redesign of my example and hence this = redesign has no relationship with my example. >>=20 >>>=20 >>> FI : That may be useful but it's not enough. What you describe only = works because you take a very specific use case, aka registration. This = fits well into DID/VC without requiring authorization per say. However = grant negotiation is still required for more general settings of = authorization. =20 >>> Please drop the next use case in the repo, so we can dive deeper = into it and see how to provide both central grant negotiation and = privacy. >>>=20 >>> FI : will do.=20 >>>=20 >>> I've added a DID example to my implementation, will publish it soon.=20= >>>=20 >>> =20 >>> Best regards. >>> /Francis >>> =20 >>>=20 >>> Then I agree with you on the audience field of the token, if left = empty it simplifies part of the problem, although it removes a big part = of the control you may want from directed tokens. That's why I'm willing = to better develop the RS hiding idea.=20 >>>=20 >>> Fabien=20 >>>=20 >>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha = > = a =C3=A9crit : >>> Hello Denis, >>>=20 >>> what you describe in the use case seems to be the default behavior = of the protocol. Let me map it with this abstract protocol flow: >> [Denis] The redesign below has no relationship with my use case. >>=20 >> A key element of my design is the User, i.e. a physical person which = initiates the exchanges. In the example below the User has disappeared. >>=20 >> A User is not a role, but an entity. >>=20 >> BTW, I can't understand the role of an "Orchestrator" (which is left = undefined).=20 >>=20 >>>=20 >>> +-----------+ +--------------+ +-----------+ +----+ = +---------------------+ >>> | Requestor | | Orchestrator | | RS | | GS | | = Resource Controller | >>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | = is | >>> | Staff | | Registr. App | | Server | | AS | | = Student | >>> +-----------+ +--------------+ +-----------+ +----+ = +---------------------+ >>> |(1) RegisterStudent | | | = | >>> |---------------------->| | | = | >>> | |(2) = RequestRecordIntent(RecordType,StudentId, >>> | | = OrchestratorId):AuthRequest[RecordType,StudentId] >>> | |<-------------->| | = | >>> | | | | = | >>> | |(3) = AuthZRequest(RecordType,StudentId,OrchestratorId) >>> | |--------------------------->| = | >>> | | | |(4) = ConsentRequest(RecordType, >>> | | | | = OrchestratorId):Consent >>> | | | = |<-------------->| >>> | |(5) = AuthZ[RecordType,StudentId,OrchestratorId] >>> | |<---------------------------| = | >>> | | | | = | >>> | |(2) = RequestRecord(RecordType,StudentId,OrchestratorId) >>> | | :RecordOf[StudentId] | = | >>> | |<-------------->| | = | >>> |(7) Registered | | | = | >>> |<----------------------| | | = | >>> + + + + = + >>>=20 >>> we assume the authz request sent by "Client" to "AS" describes the = protected resource without referring to the authz server. An AS can = issue the authz to release the graduation record of a student ((5) = AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to = the target university.=20 >>>=20 >>> What matters for this authz object is: >>> - StudentId: a reference to the student as known to the resource = server. >>> - RecordType: a reference to a resource of type graduation record as = understandable by the resource server. >>> - OrchestratorId: reference to the Orchestrator. Can be used to bind = authz to Orchestrator. >>>=20 >>> But: >>> - RS must trust AS issued token. >>> - StudentId must be known to RS, AS and Orchestrator. >>>=20 >>> Therefore, the AS does not need to know the RS. Keep the audience = field empty. >>>=20 >>> Same principle applies for the second use case. >>>=20 >>> What privacy problem do you see here? >> [Denis] The User, a physical person which initiates the exchanges has = disappeared.=20 >> No more user, no more privacy issues ? :-) >>=20 >> Denis >>=20 >>>=20 >>> Best regards. >>> /Francis >>>=20 >>> On Tue, Aug 4, 2020 at 5:08 AM Denis > wrote: >>> I tried my best twice to download three use cases in the Use cases = directory, but I failed. >>>=20 >>> Rather than failing a third time, here is the direct link of the = second try: >>>=20 >>> = https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases= -with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) = >>> Denis >>>=20 >>>=20 >>>=20 >>> --=20 >>> Francis Pouatcha >>> Co-Founder and Technical Lead >>> adorsys GmbH & Co. KG >>> https://adorsys-platform.de/solutions/ = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_2EEF5A1C-9671-4E6D-86F3-ED2AF404E3D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Denis,

I think this = is a fascinating approach that can allow for privacy-preservation in the = way that you=E2=80=99re after. Here=E2=80=99s how I would see it fitting = into GNAP:

When = the client makes the request, it includes the concealed_target_identifer = in the resources request, probably in lieu of any kind of =E2=80=9Clocatio= n=E2=80=9D field. The semantics of this field could be defined in GNAP = core or in a short extension describing the reusable field in the = =E2=80=9Cresources=E2=80=9D request:

resources: [
  =  =E2=80=9Caction": [=E2=80=9Cread=E2=80=9D],
   =E2=80=9Cconcealed_target_identifier=E2=80=9D: = =E2=80=9C876tghjkjasdf7234f=E2=80=9D
]

At that point, it=E2=80=99= s up to the AS to bind that identifier to the resulting access token and = make that information available to the RS. That could happen by packing = it into a JWT, which is likely the format you=E2=80=99d want for this = kind of thing because an introspection call from the RS would identify = the RS to the AS. 

The missing piece is a way for the client to present the = random number to the RS alongside the access token. I think this would = make sense as a separate HTTP header defined in that extension. So the = client would get back its token and send this to the RS:

Authorization: GNAP = eyj0=E2=80=A6
Target-Identifier-Random-Number: = ABE54298411...


The RS would look at the = token, find the hashed value within, and use the value in the secondary = header to recalculate and verify the hash on the request. All of this = can be done without the RS calling the AS and without the client = divulging the RS=E2=80=99s location or identity to the AS.

 =E2=80=94 = Justin


On Aug 12, 2020, at 10:34 AM, = Denis <denis.ietf@free.fr> wrote:

=20
Hi  Fabien,
=20
Thanks Denis.

A few questions to clarify: 
- "the field included into the access token = will look like a random number to the RS." - you mean AS?
=

Correct. This was a typo.

- "It should have two parts : a signed part = and an unsigned part." - Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with short expiry) between the temporary_id and the url, on the RS side?

Sorry, I am not aware of this scheme.

Then the algorithm would be :
1. Client contacts the RS, which sends a = resource description (temporary_id)

No. It is not a temporary_id. 

2. The flow continues and a token is = generated, using the temporary_id.

No. Knowing the true identifier of the = RS, the Client picks a random_number and computes a concealed_target_identifier =3D  = hash (random_number, RS_identifier).

While requesting = an access token, the Client asks the AS to include the concealed_target_identifier into the access token.

While sending the access token, the Client adds = the random_number into the unsigned part of the access token.

While receiving the access token, the RS uses it = own RS_identifier and retrieves the random_number placed into the unsigned part of the access token.
It then computes a hash of (random_number, RS_identifier). If the result matches with the concealed_target_identifier placed into the signed part of
the access token, then the access token is well targeted, otherwise it is ignored.

3. Client makes the call to the RS, using the = token. The RS verifies the signature + it also verifies that the mapping is the one expected.  

BTW, it makes the RS decide the maximum token = expiry.

Token expiration is unrelated.

The issue is that it requires more work on the = RS side, compared to a stateless JWT. 

Adding two computations using a one way = hash function is not a big deal.

 Is that correct?

No. The mechanism is fairly different. It = has already been explained once on the OAuth mailing list.

Denis

=

Fabien


On Wed, Aug 12, 2020 at = 3:24 PM Denis <denis.ietf@free.fr> wrote:
With so many messages in the last 24 = hours, I can't respond to all of them at once.
I picked the last one first.

Inline too :-)

On Wed, Aug = 12, 2020 at 1:51 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, = Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis, 

My comments are embedded = into your email with FI.

You're saying in a = follow-up message: 
"- If you want = privacy, don't expose RS identity to AS.
- If you want = transparency, expose RS identity to AS.
You can't have = both...."
While that may = seem a reasonable dichotomy at = first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access = token.

In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token. =

This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello = Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi = Francis,
I = think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request = must not mention any reference of the = RS.

FI : yes we can do that, = but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case on directed = tokens, which is an interesting topic which makes sense in many = scenarios.  
Yes. But disclosing the = protected resource discloses the RS. 

FI : yes of course. Which is why RS = hiding may be a solution. 

But as soon as you = include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by = default. 
Yes. THen default shall be = using URI of resource description and not URL to indicate resource location. 

FI : yes 

Again this doesn't mean = that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe. 
The certificate transparency = deals with something else. Does not fit in this context at all.
 
FI : It does, and has already been = implemented by some projects in relationship with OAuth2, as an additional component. 

 
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this = does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the RC in the token. SO AS = can correlate on StudentId = anyway.

FI : I disagree. It does = change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token.
Correlation on StudentId = is limited as long as it's a local identifier, i.e. not a public DID. 
How local can the StudentId = be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS = anymore.

FI : see keri or peer DID for = instance, as examples of local ID. 
Again SSI/DID/VC doesn't mean you = don't need AS, those technologies can be = complementary. 
 

As a concrete example: a = user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a = RO. 
What I suggested is that = the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements =3D> the IS knows what information = is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself. 
What do you need an AS for? = Then it can sign the claim to present to RS.

FI : to be sure, what is = "it"? 
 
 
In this case, suppose = the RO only provided consent for rs_domain/directory1 for = read. 
We now need to get back = to the AS to mint the access token. 
If AS mint access token, AS = will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is = the very reason of my question to Denis. 


If we want the AS to not = know about the RS, we either : 
- don't supply the = rs_domain at all -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization applies. In that = case I agree with your either or = statement.  
Yes 
- or find a way to hide = it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity. 

FI : yes

[Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference = with an OAuth 2.0 access token.

Either way, the AS has = not been provided any information as to where this token will effectively be = used.  

I = don't think the abstract flow deals with those privacy = concerns. 
To solve the = privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation = and no AS.

[Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful = but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation is still required for = more general settings of = authorization.  
Please drop the next use case = in the repo, so we can dive deeper into it = and see how to provide both central grant negotiation and privacy.

FI : will do. 

I've added a DID example = to my implementation, will publish it = soon. 

 
Best = regards.
/Francis
 
Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding = idea. 
Fabien 

Le mar. 11 ao=C3=BBt 2020 =C3=A0 = 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> a =C3=A9crit :
Hello Denis,

what you = describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign below has no relationship with my use case.

A key element of my design = is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.

BTW, I can't understand the role of an "Orchestrator" (which is left undefined).


+-----------+      = +--------------+  +-----------+  +----+ =  +---------------------+
| Requestor |  =     | Orchestrator | =  | RS        |  | GS |  | Resource Controller = |
| is UNIV-1 |  =     |  is UNIV-1  =  |  | is UNIV-0 |  = | or |  |        =  is          |
|   Staff  =  |      | Registr. App |  = | Server    = |  | AS |  |    =    Student       |
= +-----------+  =     +--------------+  +-----------+  +----+ =  +---------------------+
  |(1) = RegisterStudent    |    =             |        =    |                = |
  = |---------------------->|        =         |          =  |                |
  |  =                     =  |(2) RequestRecordIntent(RecordType,StudentId,
  |    =                    |  =   =  OrchestratorId):AuthRequest[RecordType,StudentId]
  |    =                   =  |<-------------->|        =    |                = |
  |  =                     =  |                |  =          |            =     |
  |  =                     =  |(3) AuthZRequest(RecordType,StudentId,OrchestratorId)
  |    =                   =  |--------------------------->|        =         |
  |  =                     =  |                |  =          |(4) = ConsentRequest(RecordType,
  |    =                    |  =               |    =        |    =  OrchestratorId):Consent
  |    =                    |  =               |    =       =  |<-------------->|
  |  =                     =  |(5) AuthZ[RecordType,StudentId,OrchestratorId]
  |  =                     =  |<---------------------------|        =         |
  |  =                     =  |                |  =          |            =     |
  |    =                   =  |(2) = RequestRecord(RecordType,StudentId,OrchestratorId)
  |    =                   =  |    =  :RecordOf[StudentId]   |  =               |
  |    =                   =  |<-------------->|        =    |                = |
  |(7) = Registered        =  |                |  =          |            =     |
  = |<----------------------|        =         |          =  |                |
  +  =                     =  +                +  =          +            =     +

we assume the authz request sent by "Client" to "AS" describes the protected resource without = referring to the authz server. An AS can issue the authz to release the graduation = record  of a student = ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to the target = university. 

What matters for this authz object = is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable  = by the resource = server.
- OrchestratorId: reference to the Orchestrator. Can be used to bind authz to = Orchestrator.

But:
- RS must trust AS issued token.
- StudentId must be known to RS, AS = and Orchestrator.

Therefore, the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use = case.

What privacy problem do you see here?

[Denis] The User, a physical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? = :-)

Denis


Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second = try:

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Serve= r-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)=

Denis


--
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
=


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

= --Apple-Mail=_2EEF5A1C-9671-4E6D-86F3-ED2AF404E3D1-- From nobody Wed Aug 12 09:32:46 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 A09473A13BD for ; Wed, 12 Aug 2020 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_MESSAGE=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 D_aNE_4B89sy for ; Wed, 12 Aug 2020 09:32:38 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 B1C473A13C1 for ; Wed, 12 Aug 2020 09:32:38 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 3so2556823wmi.1 for ; Wed, 12 Aug 2020 09:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=tiFN7rtPZpgAecHBYc4s1cmuSvsBk0yrkEqIJYnfaKg=; b=iNohGXz6JmmnhrMHcnazC8U9iQHD7gD537JmMYbEE5YO3J9BxVl9FwnPvOQb4KVxBK FzlX7234w1vTaQ4vOCox9clUVqBMeDIYbIWCEBaSE/brDPAxD6FroA35zMeC6nO2PShr kIpoxY0RVgqhTCjdYBnBtgadb+A39UyA/vL2eWdwJWZBaC98sQcvrll2AVS0RD/y8m7f 5hVq31feB3r1pym2zcWvWyJJLWAbBvbDO4BlIZ4fZWQFxP2nMH/3P8umlIdDFoq+nX9P 3MabHqwfwKfmvxZ7yMS/uGNzME0XSmvMadv1hmM4IICqEc1/F1BvF84Y046VspaTmT8d VP/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=tiFN7rtPZpgAecHBYc4s1cmuSvsBk0yrkEqIJYnfaKg=; b=JEnk7ccutlMzHhuzNvCfo2Lr32MPsemBzOfM4eq9WsC7yXOFiTMK06ifB9Gu7wj6KX +h/7/J5+A66jABMDif0Sz8kTb/4AALwxTwvaM0ls4yIRsudgbfK07eemMnKFyGaNqoy5 tJeV7ri5iF4ILhQa9Es7hviHpuLfmBNj0xj6bHaKiTX2oBccqENsZxNya8sD2RmK1lgi ws9ftg1ZkH6yMFMuZLsS9JS7vESSN1RXPWDltpFrDDYkjFKPILFSCRH07jDFnQAhJvwT F8h6UOvnPeWQIs2DP3LXXaqNE4X5mtDuCRrAnHiJOUVOLOAbfLdwKav/KZVrEmk5VcyQ 1K0A== X-Gm-Message-State: AOAM5331P0jGkVYpLJJIw6yZgPXW4LROIUoVzyXAWfn/SYC70/mM57uy 642eSxJbo6VB1GAUg7Aiqxs= X-Google-Smtp-Source: ABdhPJzkvLakifrie2y1RqeSynL14TNLaJTm6cNMpgDeiMtnEga4QrPK6j30S2rJWdIJJFh18IhGCw== X-Received: by 2002:a1c:720d:: with SMTP id n13mr473684wmc.103.1597249957084; Wed, 12 Aug 2020 09:32:37 -0700 (PDT) Received: from [10.0.0.139] (bzq-79-183-65-175.red.bezeqint.net. [79.183.65.175]) by smtp.gmail.com with ESMTPSA id o2sm4376940wmh.5.2020.08.12.09.32.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 09:32:36 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Wed, 12 Aug 2020 19:32:34 +0300 From: Yaron Sheffer To: Justin Richer , Francis Pouatcha CC: GNAP Mailing List Message-ID: <24749D16-1EFC-4817-95D4-5F7CAD5560DA@gmail.com> Thread-Topic: [GNAP] Design team formed References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> <5B49BD4E-9EE5-4B8B-A24C-981E579726A9@mit.edu> <824C513A-65F8-4D86-BE1C-4885A1B4D289@mit.edu> In-Reply-To: <824C513A-65F8-4D86-BE1C-4885A1B4D289@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3680105556_500159698" Archived-At: Subject: Re: [GNAP] Design team formed 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: Wed, 12 Aug 2020 16:32:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3680105556_500159698 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable A big +1 to Justin=E2=80=99s two responses on the design team as a temporary cons= truct, with the challenge of bringing a document back to the full working gr= oup, a document that will serve as a *starting point* for our work. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Justin Richer Date: Wednesday, August 12, 2020 at 19:05 To: Francis Pouatcha Cc: Yaron Sheffer , GNAP Mailing List Subject: Re: [GNAP] Design team formed =20 The goal of the design team is to take a step aside from the public mailing= list and, hopefully, get more done in a short time period. Discussion on a = public mailing list is powerful, but slow and prone to derailing and miscomm= unication. The design team will discuss things more directly to avoid those = problems in the short term, much the way that a small subcommittee can bring= targeted expertise to a group=E2=80=99s problem by using higher bandwidth communi= cation channels and regular interaction. The results will be brought back to= the list to be discussed and, hopefully, adopted as a starting point. That = starting point document will then be debated, edited, and refined by the wor= king group. Nothing in the starting document is sacred, but at least it will= be something concrete to build on. =20 While the design team is working, discussion will continue on the list, and= all the design team members are still participating on the list. This ongoi= ng conversation is still very valuable for the group as a whole, including t= he design team, even if it=E2=80=99s not a direct feed of the design team=E2=80=99s disc= ussions.=20 =20 There are a LOT of amazing people in this group =E2=80=94 I see that as a testame= nt to how important this problem space is and how much of an appetite there = is for solving things in that space. This process is going to take a while, = maybe years of debate and engineering before we reach a final standard. Ther= e is going to be a lot of opportunity to contribute, and I look forward to y= our continuing contributions. =20 The IETF has this writeup on the nature and utility of design teams, which = you might find useful: https://www.ietf.org/about/groups/iesg/statements/des= ign-teams/ =20 =20 =E2=80=94 Justin On Aug 12, 2020, at 11:31 AM, Francis Pouatcha wrote: =20 Justin, =20 Thanks for your response. I hope the design team will keep addressing essen= tial topics on the list so we can contribute. =20 Best regards. /Francis =20 On Wed, Aug 12, 2020 at 11:24 AM Justin Richer wrote: Francis, =20 The design team is just a temporary construct to get things started here, a= nd it will dissolve back into the WG when the task is over. I, for one, am r= eally thankful to have you bring your experience to this working group. I=E2=80=99= ve appreciated your contributions greatly so far, and I look forward to cont= inuing to work with you. =20 We still have a long way to go and a lot of work to do. The output of the d= esign team is just the start of the working group, and there are many more t= hings to figure out. =20 =E2=80=94 Justin On Aug 11, 2020, at 1:25 PM, Francis Pouatcha wrote: =20 It is unfortunate I didn't make it. Would have liked to bring in my 22 year= s of experience in building authz applications. =20 Best regards. /Francis =20 On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer wrote= : Thank you all for attending the inaugural GNAP meeting at IETF-108. We had = quite a few volunteers, and the chairs picked the following people for the d= esign team: * Kathleen Moriarty * Justin Richer * Dick Hardt * Mike Jones * Fabien Imbault Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered! We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is as= usual subject to approval by the whole working group. Thanks, Leif and Yaron --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 =20 --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ =20 --B_3680105556_500159698 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

A big +1 to Justin=E2=80=99s two responses on the design= team as a temporary construct, with the challenge of bringing a document ba= ck to the full working group, a document that will serve as a *starting p= oint* for our work.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From= : Justin Richer <jr= icher@mit.edu>
Date: Wednesday, August 12, 2020 at 19:05
= To: Francis Pouatcha <fpo@adorsys.de>
Cc: Yaron Sheffer = <yaronf.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>
= Subject: Re: [GNAP] Design team formed

 

The goal = of the design team is to take a step aside from the public mailing list and,= hopefully, get more done in a short time period. Discussion on a public mai= ling list is powerful, but slow and prone to derailing and miscommunication.= The design team will discuss things more directly to avoid those problems i= n the short term, much the way that a small subcommittee can bring targeted = expertise to a group=E2=80=99s problem by using higher bandwidth communication cha= nnels and regular interaction. The results will be brought back to the list = to be discussed and, hopefully, adopted as a starting point. That starting p= oint document will then be debated, edited, and refined by the working group= . Nothing in the starting document is sacred, but at least it will be someth= ing concrete to build on.

 <= /o:p>

While the design team is working, dis= cussion will continue on the list, and all the design team members are still= participating on the list. This ongoing conversation is still very valuable= for the group as a whole, including the design team, even if it=E2=80=99s not a d= irect feed of the design team=E2=80=99s discussions. 

 

Ther= e are a LOT of amazing people in this group =E2=80=94 I see that as a testament to= how important this problem space is and how much of an appetite there is fo= r solving things in that space. This process is going to take a while, maybe= years of debate and engineering before we reach a final standard. There is = going to be a lot of opportunity to contribute, and I look forward to your c= ontinuing contributions.

&n= bsp;

The IETF has this writeup on the= nature and utility of design teams, which you might find useful: https:/= /www.ietf.org/about/groups/iesg/statements/design-teams/

<= /div>

 

 

 =E2=80=94 Justin=



On Aug 12, 202= 0, at 11:31 AM, Francis Pouatcha <fpo@ado= rsys.de> wrote:

 

Justin,

 

Thanks for your&nbs= p;response. I hope the design team will keep addressing essential topics on = the list so we can contribute.

<= o:p> 

Best regards.

/Francis

 

On Wed, Aug 12, = 2020 at 11:24 AM Justin Richer <jricher@= mit.edu> wrote:

Francis,

 

The design tea= m is just a temporary construct to get things started here, and it will diss= olve back into the WG when the task is over. I, for one, am really thankful = to have you bring your experience to this working group. I=E2=80=99ve appreciated = your contributions greatly so far, and I look forward to continuing to work = with you.

 

<= /div>

We still have a long way to go and a lot of wor= k to do. The output of the design team is just the start of the working grou= p, and there are many more things to figure out.

 

 =E2=80= =94 Justin



O= n Aug 11, 2020, at 1:25 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>= ; wrote:

 

It is unfortunate I didn't make it. Would have liked t= o bring in my 22 years of experience in building authz applications.

 

Best regards.

/Francis

 

On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer <yaronf.ietf@gmail.com> w= rote:

<= p class=3DMsoNormal>Thank you all for attending the inaugural GNAP meeting at = IETF-108. We had quite a few volunteers, and the chairs picked the following= people for the design team:

* Kathleen Moriarty
* Justin Richer* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graci= ously agreed to convene the sessions and report on the team's outcome. Thank= you all who volunteered!

We expect the design team to decide on a so= lution outline that combines the best of both proposals, and present this ou= tline by Sep. 15. Anything is as usual subject to approval by the whole work= ing group.

Thanks,
        Leif and Yaron
<= br>

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


=

 

--

Francis Pouatcha

= Co-Founder and Technical Lead

ad= orsys GmbH & Co. KG

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

 


 =

--

Francis Pouatcha

Co-Founder and Technical Lead

<= /div>

adorsys GmbH & Co. KG

<= div>

https://adorsys-platform.de/solutions/

<= /div>

 

--B_3680105556_500159698-- From nobody Wed Aug 12 09:34:46 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 83C693A111E for ; Wed, 12 Aug 2020 09:34:45 -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 tacTZ-bx6GLj for ; Wed, 12 Aug 2020 09:34:42 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 EE8A43A13C1 for ; Wed, 12 Aug 2020 09:34:41 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id d190so2324178wmd.4 for ; Wed, 12 Aug 2020 09:34:41 -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=zGwW7FXhZX7r9QrrYdRR2OsPCAD5qrwE8iFmXVxgMPU=; b=DG0iSpXj7DveupxwcUnfpXlZsr61xYG3hIWH4g5VSNdQvauaw4hGpCCRRKkmzOfHUf 58BtDF89qAezOMIflB2EPkJ4Doc1OJ+JkQDdoYguapH6FDtX1SDBz7ed9ehlh+0iCl3o QZ4gha+W1iOmrTe5iM3THPguYbPKbBNRN2I1c= 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=zGwW7FXhZX7r9QrrYdRR2OsPCAD5qrwE8iFmXVxgMPU=; b=iDMrueziFwm9FlM4MGu2D5Z8d548SoRGAFhSDmeOpNBiaOI9DVdo4UfYMpQJhSGqUM 3W7BalKFThizNgC8OEnE1WD6uiEHz/oz5D9QnUgFPrRMYQ92lXYdhOC+S1cVkOem8ss1 72aTEYjBhwATh50eQ9Cm3DmjPxVpKJXomOSg+aIvmJkjSLO5wZ6LBY1UjcRYSgUP4LKQ z9YuHA5Xy9h04INr7nMi0Lb04a30VKs7SybbdWp88MJ6VYP226Nz7m/NM3HRY6UbsYxA 5ssBn03zg3FLECllsXX9BHab93N7+3/JKerUqMzjNgbsPxNp3AGhRFIohwT44ef6z8h0 5edw== X-Gm-Message-State: AOAM5317xTdxq2HDQ2S/dj+iiL1Rq3XqzSOMJ9CyDnpYAB3raAIOYRoy ZWzqFxETN1Ro2bqOhC3VnoNd8+2LSKzu+AIDQ61UkQ== X-Google-Smtp-Source: ABdhPJwf7cKQ4SvO/fXGXJcyuHqAEP6h5ABxBcuP3Kmrw9hseQ9877IB89ttRLrR23pCE3RIr3SAHX6zLcsjGCQjAXo= X-Received: by 2002:a1c:3985:: with SMTP id g127mr492306wma.64.1597250080141; Wed, 12 Aug 2020 09:34:40 -0700 (PDT) MIME-Version: 1.0 References: <6AE4B49F-3C99-4C04-98C8-5089398714A7@gmail.com> <5B49BD4E-9EE5-4B8B-A24C-981E579726A9@mit.edu> <824C513A-65F8-4D86-BE1C-4885A1B4D289@mit.edu> In-Reply-To: <824C513A-65F8-4D86-BE1C-4885A1B4D289@mit.edu> From: Francis Pouatcha Date: Wed, 12 Aug 2020 12:34:29 -0400 Message-ID: To: Justin Richer Cc: Yaron Sheffer , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a5098c05acb0c369" Archived-At: Subject: Re: [GNAP] Design team formed 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: Wed, 12 Aug 2020 16:34:46 -0000 --000000000000a5098c05acb0c369 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Justin, Yaron, Thanks for this reference. Even though the design team document is just an input for the working group, the drafted structure generally defines the fundament. Is there any reason to limit the design team to 5 participants? I still do believe my contribution to the basic structure will be too substantial to be fitted afterward in a published initial draft. I hereby apply again to be part of that initial team, and I do believe there is a lot for me to bring in there now. Best regards. /Francis On Wed, Aug 12, 2020 at 12:05 PM Justin Richer wrote: > The goal of the design team is to take a step aside from the public > mailing list and, hopefully, get more done in a short time period. > Discussion on a public mailing list is powerful, but slow and prone to > derailing and miscommunication. The design team will discuss things more > directly to avoid those problems in the short term, much the way that a > small subcommittee can bring targeted expertise to a group=E2=80=99s prob= lem by > using higher bandwidth communication channels and regular interaction. Th= e > results will be brought back to the list to be discussed and, hopefully, > adopted as a starting point. That starting point document will then be > debated, edited, and refined by the working group. Nothing in the startin= g > document is sacred, but at least it will be something concrete to build o= n. > > While the design team is working, discussion will continue on the list, > and all the design team members are still participating on the list. This > ongoing conversation is still very valuable for the group as a whole, > including the design team, even if it=E2=80=99s not a direct feed of the = design > team=E2=80=99s discussions. > > There are a LOT of amazing people in this group =E2=80=94 I see that as a > testament to how important this problem space is and how much of an > appetite there is for solving things in that space. This process is going > to take a while, maybe years of debate and engineering before we reach a > final standard. There is going to be a lot of opportunity to contribute, > and I look forward to your continuing contributions. > > The IETF has this writeup on the nature and utility of design teams, whic= h > you might find useful: > https://www.ietf.org/about/groups/iesg/statements/design-teams/ > > > =E2=80=94 Justin > > On Aug 12, 2020, at 11:31 AM, Francis Pouatcha wrote: > > Justin, > > Thanks for your response. I hope the design team will keep addressing > essential topics on the list so we can contribute. > > Best regards. > /Francis > > On Wed, Aug 12, 2020 at 11:24 AM Justin Richer wrote: > >> Francis, >> >> The design team is just a temporary construct to get things started here= , >> and it will dissolve back into the WG when the task is over. I, for one,= am >> really thankful to have you bring your experience to this working group. >> I=E2=80=99ve appreciated your contributions greatly so far, and I look f= orward to >> continuing to work with you. >> >> We still have a long way to go and a lot of work to do. The output of th= e >> design team is just the start of the working group, and there are many m= ore >> things to figure out. >> >> =E2=80=94 Justin >> >> On Aug 11, 2020, at 1:25 PM, Francis Pouatcha < >> fpo=3D40adorsys.de@dmarc.ietf.org> wrote: >> >> It is unfortunate I didn't make it. Would have liked to bring in my 22 >> years of experience in building authz applications. >> >> Best regards. >> /Francis >> >> On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer >> wrote: >> >>> Thank you all for attending the inaugural GNAP meeting at IETF-108. We >>> had quite a few volunteers, and the chairs picked the following people = for >>> the design team: >>> >>> * Kathleen Moriarty >>> * Justin Richer >>> * Dick Hardt >>> * Mike Jones >>> * Fabien Imbault >>> >>> Kathleen has graciously agreed to convene the sessions and report on th= e >>> team's outcome. Thank you all who volunteered! >>> >>> We expect the design team to decide on a solution outline that combines >>> the best of both proposals, and present this outline by Sep. 15. Anythi= ng >>> is as usual subject to approval by the whole working group. >>> >>> Thanks, >>> Leif and Yaron >>> >>> >>> >>> -- >>> 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/ >> -- >> 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/ > > > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000a5098c05acb0c369 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Justin, Yaron,

Thanks = for this reference. Even though the design team document is just an input f= or the working group, the drafted structure generally defines the fundament= .

Is there any reason to limit the design team to = 5 participants? I still do believe my contribution to the basic structure w= ill be too substantial to be fitted afterward in a published initial draft.=

I hereby apply again to be part of that initial t= eam, and I do believe there is a lot for me to bring in there now.

Best regards.
/Francis

=

On Wed, Aug 12, 2020 at 12:05 PM Justin Richer <jricher@mit.edu> wrote:
The goal of the design team is to take a step aside from the public mail= ing list and, hopefully, get more done in a short time period. Discussion o= n a public mailing list is powerful, but slow and prone to derailing and mi= scommunication. The design team will discuss things more directly to avoid = those problems in the short term, much the way that a small subcommittee ca= n bring targeted expertise to a group=E2=80=99s problem by using higher ban= dwidth communication channels and regular interaction. The results will be = brought back to the list to be discussed and, hopefully, adopted as a start= ing point. That starting point document will then be debated, edited, and r= efined by the working group. Nothing in the starting document is sacred, bu= t at least it will be something concrete to build on.

Wh= ile the design team is working, discussion will continue on the list, and a= ll the design team members are still participating on the list. This ongoin= g conversation is still very valuable for the group as a whole, including t= he design team, even if it=E2=80=99s not a direct feed of the design team= =E2=80=99s discussions.=C2=A0

There are a LOT of a= mazing people in this group =E2=80=94 I see that as a testament to how impo= rtant this problem space is and how much of an appetite there is for solvin= g things in that space. This process is going to take a while, maybe years = of debate and engineering before we reach a final standard. There is going = to be a lot of opportunity to contribute, and I look forward to your contin= uing contributions.

The IETF has this writeup on t= he nature and utility of design teams, which you might find useful:=C2=A0https://www.ietf.org/about/groups/iesg/statements/design-t= eams/


=C2=A0=E2=80=94 Justin

On Aug 12, 2020, at 11:31 AM, Fran= cis Pouatcha <fpo@ad= orsys.de> wrote:

Justin,

Thanks for your=C2=A0response. I hope the design team will keep addr= essing essential topics on the list so we can contribute.

Best regards.
/Francis

On Wed, Aug 12, 2020 at 11:24= AM Justin Richer <= jricher@mit.edu> wrote:
Francis,

The design team is just a t= emporary construct to get things started here, and it will dissolve back in= to the WG when the task is over. I, for one, am really thankful to have you= bring your experience to this working group. I=E2=80=99ve appreciated your= contributions greatly so far, and I look forward to continuing to work wit= h you.

We still have a long way to go and a lot of= work to do. The output of the design team is just the start of the working= group, and there are many more things to figure out.

<= div>=C2=A0=E2=80=94 Justin

On Au= g 11, 2020, at 1:25 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org<= /a>> wrote:

It is unfortunate I didn'= t make it. Would have liked to bring in my 22 years of experience in buildi= ng authz applications.

Best regards.
/Francis<= /div>

On Tue, Aug 11, 2020 at 6:43 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:=
Thank you all f= or attending the inaugural GNAP meeting at IETF-108. We had quite a few vol= unteers, and the chairs picked the following people for the design team:
* Kathleen Moriarty
* Justin Richer
* Dick Hardt
* Mike Jones
* Fabien Imbault

Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered!

We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron



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


--
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 &a= mp; Co. KG
=



--
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
--000000000000a5098c05acb0c369-- From nobody Wed Aug 12 09:40:05 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 65FCB3A13BD for ; Wed, 12 Aug 2020 09:40:04 -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 YjipapLtjFo0 for ; Wed, 12 Aug 2020 09:40:01 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 10A723A1434 for ; Wed, 12 Aug 2020 09:39:57 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id p14so2355222wmg.1 for ; Wed, 12 Aug 2020 09:39:57 -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=GoZri52yRcQXXJcTMmEqzOLuS3983gfe4Yq8/7+nXtw=; b=hMFyHvomrvH7f24jpuUzIecy0y+kGOb3WPb95b4MyglCCq0RXDNcvzlE2990Dj8J5b iHDgVmUa1aLojvWFFKfrYbwVOgWXnGNTC/tMUHMCsiEmdQnLqm3Sz2n4GgXboQ03hc5V JKIyzPKock+yVEVT2biZ8ooDKeWkj+dy5AH0g= 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=GoZri52yRcQXXJcTMmEqzOLuS3983gfe4Yq8/7+nXtw=; b=iNqHV/AgisNq/lE5I4lXpnhiDgvJKEEwC8tZFgkrvabyDzdo0i+VSUQRApmKYkgtdx ijfQoLHV9FOc+DDGRHNTzbItGfUzfGrSJs/d2iSHKju5dLNV+rmfnlFHvZlFSWcifY+w w1a6N8EMhOF9lMInDqAo0aAT09697C7GDoJxdQ+5Gh9l7NBOTeltbMPsP1uA//TlMZN6 0zB54ULboI5S/BOGYN48WiHKu1vPsJe4D/0biea+GrWW6rBVisiOOkc97VVleAwgF0zO 7W+59cKxnIlp7Sg/puYWkPQcl0rG8nlhMToyFTvuYyXcH08W9G8nXQ5eUnV/WT0Q+W/V t+fQ== X-Gm-Message-State: AOAM532396vga84x7szmtsjof6YnYoDcw2EAQd/9jVOD9kIcdeh6UYKY WUTNDz3/FE7RSSVoubVGxeoMjOp0tSyZkivwroqpPA== X-Google-Smtp-Source: ABdhPJwvjyaXrIDJY/hYRF2ZX2EXkO3rwSsmt1voaMnJ1Y6McEXhjecVGC5iXCqBJvGDbHvcLlzsJxTgJHqFhsEeYGQ= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr542881wmj.8.1597250396196; Wed, 12 Aug 2020 09:39:56 -0700 (PDT) MIME-Version: 1.0 References: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> In-Reply-To: From: Francis Pouatcha Date: Wed, 12 Aug 2020 12:39:45 -0400 Message-ID: To: Fabien Imbault Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000007bb9b905acb0d60f" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 16:40:04 -0000 --0000000000007bb9b905acb0d60f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for temporary_id. Solves the privacy issue, but requires Step (2). On Wed, Aug 12, 2020 at 10:13 AM Fabien Imbault wrote: > Thanks Denis. > > A few questions to clarify: > - "the field included into the access token will look like a random numbe= r > to the RS." - you mean AS? > - "It should have two parts : a signed part and an unsigned part." - > Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (wit= h > short expiry) between the temporary_id and the url, on the RS side? > > Then the algorithm would be : > 1. Client contacts the RS, which sends a resource description > (temporary_id) > 2. The flow continues and a token is generated, using the temporary_id > 3. Client makes the call to the RS, using the token. The RS verifies the > signature + it also verifies that the mapping is the one expected. > > BTW, it makes the RS decide the maximum token expiry. > The issue is that it requires more work on the RS side, compared to a > stateless JWT. > > Is that correct? > > Fabien > > > On Wed, Aug 12, 2020 at 3:24 PM Denis wrote: > >> With so many messages in the last 24 hours, I can't respond to all of >> them at once. >> I picked the last one first. >> >> Inline too :-) >> >> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha wrote: >> >>> Hello Fabian, inline >>> >>> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> My comments are embedded into your email with FI. >>>> >>>> You're saying in a follow-up message: >>>> "- If you want privacy, *don't* expose RS identity to AS. >>>> - If you want transparency, expose RS identity to AS. >>>> You can't have both...." >>>> While that may seem a reasonable dichotomy at first sight, I believe >>>> the reality is actually more nuanced and depends on how we end up desi= gning >>>> the system. >>>> >>> [Denis] This is in fact more nuanced. It is possible to prevent the AS >> to know who the RS is by hiding the true identifier of the RS to the AS. >> >> This means that for security reasons the access token is still targeted >> but that the field included into the access token will look like a rando= m >> number to the RS. >> That random number will change for every access token. >> >> In order for the RS to make sure that the access token is indeed intende= d >> for itself, it will need to combine the field included into the access >> token >> with an unsigned field external to the access token. >> >> This would have a major consequence for the structure of a GNAP access >> token that will be rather different from an OAuth 2.0 access token. >> It should have two parts : a signed part and an unsigned part. >> >> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha >>>> wrote: >>>> >>>>> Hello Fabian, >>>>> >>>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I think Denis points to the fact that, in the current situation, the >>>>>> AS receives the resource request from the Client and therefore knows= what >>>>>> tokens are asked. >>>>>> >>>>> The token request must not mention any reference of the RS. >>>>> >>>> >>>> FI : yes we can do that, but as Tom commented, it's not a general rule= . >>>> And for instance in XYZ you do describe the URL of the resource. See a= lso >>>> the use case on directed tokens, which is an interesting topic which m= akes >>>> sense in many scenarios. >>>> >>> Yes. But disclosing the protected resource discloses the RS. >>> >> >> FI : yes of course. Which is why RS hiding may be a solution. >> >>> >>> But as soon as you include that possibility, it's fair to think that >>>> this capability could be used for surveillance purposes in some cases, >>>> unless you found a privacy by design scheme that applies by default. >>>> >>> Yes. THen default shall be using URI of resource description and not UR= L >>> to indicate resource location. >>> >> >> FI : yes >> >>> >>> Again this doesn't mean that transparency requirements aren't important >>>> too, but I think there are other ways it can be achieved (for instance= , an >>>> inspiration is the certificate transparency project). Could be an exte= nsion >>>> to the protocol I believe. >>>> >>> The certificate transparency deals with something else. Does not fit in >>> this context at all. >>> >>> >> FI : It does, and has already been implemented by some projects in >> relationship with OAuth2, as an additional component. >> >>> >>>> >>>>> >>>>>> Then it also implements the consent interface (and possibly the logi= n >>>>>> too) and so it also knows who validates and what is accepted or not. >>>>>> >>>>> Decoupling this does not change the privacy context, as the AS issues >>>>> the Token. AS needs to add a reference to the RC in the token. SO AS = can >>>>> correlate on StudentId anyway. >>>>> >>>> >>>> FI : I disagree. It does change the privacy context, if as Denis >>>> suggested, the consent is made outside of the AS and if you don't send= to >>>> the AS the information on the RS when it needs to issue the token. >>>> Correlation on StudentId is limited as long as it's a local identifier= , >>>> i.e. not a public DID. >>>> >>> How local can the StudentId be? It is known to both universities and to >>> the AS. Without a public reference, you can not link information betwee= n >>> unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Th= en >>> you do not need central AS anymore. >>> >> >> FI : see keri or peer DID for instance, as examples of local ID. >> Again SSI/DID/VC doesn't mean you don't need AS, those technologies can >> be complementary. >> >> >>> >>>> As a concrete example: a user may want to use an application to access >>>> rs_domain/directory1 and rs_domain/directory2 in read and write, which= are >>>> managed by a RO. >>>> What I suggested is that the Client may (optionally) carry out its >>>> consent through a decoupled IS server (separated from the AS), that >>>> displays the UI based on the RS requirements =3D> the IS knows what >>>> information is used, but the IS may be chosen by the IS independently = from >>>> the AS or even run by the Client itself. >>>> >>> What do you need an AS for? Then it can sign the claim to present to RS= . >>> >> >> FI : to be sure, what is "it"? >> >> >>> >>> >>>> In this case, suppose the RO only provided consent for >>>> rs_domain/directory1 for read. >>>> We now need to get back to the AS to mint the access token. >>>> >>> If AS mint access token, AS will be able to correlate. Unless start >>> applying intransparent complex reference mapping techniques, wich might >>> even open room for new attack vectors. >>> >> >> FI : not necessarily with respect to correlation, see above. >> As for mapping techniques, this is the very reason of my question to >> Denis. >> >>> >>> >>>> If we want the AS to not know about the RS, we either : >>>> - don't supply the rs_domain at all -> the JWT says that directory1 in >>>> read access is authorized. The downside is that we actually cannot con= trol >>>> to which URL the authorization applies. In that case I agree with your >>>> either or statement. >>>> >>> Yes >>> >>>> - or find a way to hide it (not sure if that's practical, hence my >>>> questions on RS hiding). This would have the benefit of still allowing >>>> directed tokens -> the JWT says that rs_petname/directory1 in read acc= ess >>>> is authorized. >>>> >>> More complexity. >>> >> >> FI : yes >> >> [Denis] As indicated at the top of this email, it is possible to always >> hide the identifier of the RS while still targetting every access token. >> >> BTW, I have expanded the notion of targetting by allowing to place into = a >> target field of an access token either or both a RS identifier and >> a Service Name (SN) identifier to which the RS belongs. >> >> Two targetting fields should hence be possible: a RS identifier and a SN >> identifier. >> >> This is also a difference with an OAuth 2.0 access token. >> >> Either way, the AS has not been provided any information as to where thi= s >>>> token will effectively be used. >>>> >>> >>>>> >>>>>> I don't think the abstract flow deals with those privacy concerns. >>>>>> >>>>> To solve the privacy problem addressed in this thread, we need to go >>>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to is= sue a >>>>> VC (Verifiable Credential) to the Student (in his role of RC). The St= udent >>>>> will then present this claim to UNIV-1 during his registration. In th= is >>>>> case we need no Grant negotiation and no AS. >>>>> >>>> [Denis] This is a complete redesign of my example and hence this >> redesign has no relationship with my example. >> >> >>>> FI : That may be useful but it's not enough. What you describe only >>>> works because you take a very specific use case, aka registration. Thi= s >>>> fits well into DID/VC without requiring authorization per say. However >>>> grant negotiation is still required for more general settings of >>>> authorization. >>>> >>> Please drop the next use case in the repo, so we can dive deeper into i= t >>> and see how to provide both central grant negotiation and privacy. >>> >> >> FI : will do. >> >>> >>> I've added a DID example to my implementation, will publish it soon. >>>> >>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>>> >>>>>> Then I agree with you on the audience field of the token, if left >>>>>> empty it simplifies part of the problem, although it removes a big p= art of >>>>>> the control you may want from directed tokens. That's why I'm willin= g to >>>>>> better develop the RS hiding idea. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>>> >>>>>>> Hello Denis, >>>>>>> >>>>>>> what you describe in the use case seems to be the default behavior >>>>>>> of the protocol. Let me map it with this abstract protocol flow: >>>>>>> >>>>>> [Denis] The redesign below has no relationship with my use case. >> >> A key element of my design is the User, i.e. a physical person which >> initiates the exchanges. In the example below the User has disappeared. >> >> A User is not a role, but an entity. >> >> BTW, I can't understand the role of an "Orchestrator" (which is left >> undefined). >> >> >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>>> Resource Controller | >>>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>>> is | >>>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>>> Student | >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> |(1) RegisterStudent | | | >>>>>>> | >>>>>>> |---------------------->| | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>>> | | >>>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(3) >>>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>>> | |--------------------------->| >>>>>>> | >>>>>>> | | | |(4) >>>>>>> ConsentRequest(RecordType, >>>>>>> | | | | >>>>>>> OrchestratorId):Consent >>>>>>> | | | >>>>>>> |<-------------->| >>>>>>> | >>>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>>> | |<---------------------------| >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>>> | | :RecordOf[StudentId] | >>>>>>> | >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> |(7) Registered | | | >>>>>>> | >>>>>>> |<----------------------| | | >>>>>>> | >>>>>>> + + + + >>>>>>> + >>>>>>> >>>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>>> protected resource without referring to the authz server. An AS can= issue >>>>>>> the authz to release the graduation record of a student >>>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refer= ence to >>>>>>> the target university. >>>>>>> >>>>>>> What matters for this authz object is: >>>>>>> - StudentId: a reference to the student as known to the resource >>>>>>> server. >>>>>>> - RecordType: a reference to a resource of type graduation record a= s >>>>>>> understandable by the resource server. >>>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bin= d >>>>>>> authz to Orchestrator. >>>>>>> >>>>>>> But: >>>>>>> - RS must trust AS issued token. >>>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>>> >>>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>>> field empty. >>>>>>> >>>>>>> Same principle applies for the second use case. >>>>>>> >>>>>>> What privacy problem do you see here? >>>>>>> >>>>>> [Denis] The User, a physical person which initiates the exchanges ha= s >> disappeared. >> No more user, no more privacy issues ? :-) >> >> Denis >> >> >>>>>>> Best regards. >>>>>>> /Francis >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>>> >>>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>>> directory, but I failed. >>>>>>>> >>>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>>> second try: >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-u= se-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> -- >>> 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 >> > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000007bb9b905acb0d60f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for temporary_id. Solves the privacy issue, but require= s Step (2).

On Wed, Aug 12, 2020 at 10:13 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Thanks Denis.

A few questions to cla= rify:=C2=A0
- "the field included into the access token will look like a random number to the RS." - = you mean AS?
- "It should have two parts : a signed part= and an unsigned part." - Something like an authenticated cipher (e.g.= AES-GCM) + a KV mapping (with short expiry) between the temporary_id and t= he url, on the RS side?

Then the algorithm would b= e :
1. Client contacts the RS, which sends a resource description= (temporary_id)
2. The flow continues and a token is generated, u= sing the temporary_id
3. Client makes the call to the RS, using t= he token. The RS verifies the signature=C2=A0+ it also verifies that the ma= pping is the one expected.=C2=A0=C2=A0

BTW, it mak= es the RS decide the maximum token expiry.
The issue is that it r= equires more work on the RS side, compared to a stateless JWT.=C2=A0 =C2=A0=

Is that correct?

Fab= ien


On Wed, Aug 12, 2020 at 3:24 PM Denis <denis.ietf@free.fr>= wrote:
=20 =20 =20
With so many messages in the last 24 hours, I can't respond to all of them at once.
I picked the last one first.

=20
Inline too :-)

On Wed, Aug 12, 2020 at 1:5= 1 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,=C2=A0

My comments are embedded into your email with FI.

You're saying in a follow-up message:=C2=A0<= /div>
"- If you want privacy,=C2=A0don't=C2=A0expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem=C2=A0a reasonable=C2=A0dicho= tomy=C2=A0at first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access token.

In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token.

This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case=C2=A0on directed tokens, which is an interesting topic which makes sense in many scenarios.=C2=A0=C2=A0
Yes. But disclosing the protected resource discloses the RS.=C2=A0

FI : yes of course. Which is why RS hiding may be a solution.=C2=A0

But as soon as you include that possibility, it's fair to think that this capability could b= e used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default.=C2=A0
Yes. THen default shall be using URI of resource description and not URL to indicate resource location.=C2=A0

FI : yes=C2=A0

Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe.=C2=A0
The certificate transparency deals with something else. Does not fit in this context at all.
=C2=A0
FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component.=C2=A0

=C2=A0
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the=C2=A0RC in the token. SO AS can correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID.=C2=A0
How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples of local ID.=C2=A0
Again SSI/DID/VC doesn't mean you don't need AS, tho= se technologies can be complementary.=C2=A0
=C2=A0

As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO.=C2=A0
What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements =3D> the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself.=C2=A0
What do you need an AS for? Then it can sign the claim to present to RS.

FI : to be sure, what is "it"?=C2=A0
=C2=A0
=C2=A0
In this case, suppose the RO only provided consent for rs_domain/directory1 for read.=C2=A0
We now need to get back to the AS to mint the access token.=C2=A0
If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis.=C2=A0


If we want the AS to not know about the RS, we either :=C2=A0
- don't supply the rs_domain at all -> th= e JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization=C2=A0applies. In that case I agree wi= th your either or statement.=C2=A0=C2=A0
Yes=C2=A0
- or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity.=C2=A0

FI : yes

[Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference with an OAuth 2.0 access token.

Either way, the AS has not been provided any information as to where this token will effectively be used.=C2=A0=C2=A0


I don't think the abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and=C2=A0no AS.

[Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation=C2=A0is still required for more general settings of authorization.=C2=A0=C2=A0
Please drop the next use case in the=C2=A0repo, so we can dive deeper into it and see how to provide both central grant negotiation=C2=A0and privacy.

FI : will do.=C2=A0

I've added a DID example to my implementation, will publish it soon.=C2=A0

=C2=A0
Best regards.
/Francis
=C2=A0

Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea.=C2=A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Fran= cis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org&= gt; a =C3=A9crit=C2=A0:
Hello=C2=A0Denis,

what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.<= /p>

BTW, I can't understand the role of an "Orchestrator" (which is left undefined).


+------= -----+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0= | Orchestrator | =C2=A0|=C2=A0RS=C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Con= troller |
| is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 is UNIV-1=C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |= =C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |= =C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0= =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
=C2=A0 |(1) RegisterStudent=C2=A0= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId,
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):AuthRequest= [RecordType,StudentId]
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |=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) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|--------------------------= ->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) ConsentRequest(RecordType,=
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Consent
=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->| =C2=A0 |=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=A0AuthZ[RecordType,= StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<----------------------= -----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) RequestRecord(RecordType,Studen= tId,OrchestratorId)
=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:RecordOf[StudentId]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) Registered=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +

we assume the authz request sent by "Client" to "AS"= ; describes the protected resource without referring=C2=A0to the authz server. An AS can issue the authz to release the graduation record=C2=A0 of a student ((5)=C2=A0AuthZ[RecordType,StudentI= d,OrchestratorId]), without any reference to the target university.=C2=A0

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable=C2=A0 by t= he resource server.
-=C2=A0Or= chestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.<= /div>
-=C2=A0St= udentId must be known to RS, AS and=C2=A0Orchestrator.

Therefore= , the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.

What privacy problem do you see here?

[Denis] The User, a physical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? :-)

Denis


Best regards.
/Francis<= /font>

O= n Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-gnap/general/wiki/Thr= ee-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Desig= n%22-(PbD)

Denis


--
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
https://= adorsys-platform.de/solutions/
--0000000000007bb9b905acb0d60f-- From nobody Wed Aug 12 09:40:46 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 6F79E3A1120 for ; Wed, 12 Aug 2020 09:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 zFt9j3zdsC4P for ; Wed, 12 Aug 2020 09:40:40 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 2E9AF3A114C for ; Wed, 12 Aug 2020 09:40:40 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id w25so2952449ljo.12 for ; Wed, 12 Aug 2020 09:40:39 -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=k2A9W2sDE2vcTkc+wDW+IQ18m2GHniXbYvPPNsk85YI=; b=otUB4avkg6us6pMIw65qPc4fRwZApFBUYFIaAM5y//UUxhY4puxImosj6hAd8gV6Nu 8TWyZ9xONa762RpzGp94Gv+K51gsf2Ao5kuvk1YKRVO+3Nzucus+kCpiHdPv8oaS/eLg ex5xS9zFiBFjf/pOMtnfM6VsG1CkdUOKMlcKAlWgOLdBiqI1OgeTV3ERyJ29+ztlntRP gzUx6YvCLy1cFlD9Q24AvwDKAww2O61jKPjMlHGu8xarWG9pXqKAi7d9Iw5PsXJtOYpp pITsq8iKv+lJ6fxCPPi0V3/33vdXOusRYzLlAN6VQp7jeU5vsfqohXF+UXPTYovwa7H9 NF0A== 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=k2A9W2sDE2vcTkc+wDW+IQ18m2GHniXbYvPPNsk85YI=; b=iLkM1sDL3gx81INfyQjj9zlu8DoDA1YXR6MeoomkfMXdkcOf6o32ipLvChtg7tIZYl v7ZDSlptJvZbdj+QFM0g6rYOUEET/WSFGQY85WtnwKAx2X25adlnz7vZwkKDOMJ+lqO4 vGRA0pSTUM9LBO9pwV17gkegho7tqUTh+2zjTERjjy9JEUqElv7vZtEG0L9q2kuN8hMC f1s4I/4gAr/qBWlmZ3aQ9io78RSYjvPx+cjRXwBbxZXkZASwihk+ElRlpjsT/FawdxCt ziY2+CWYakVu5o4fHdVBMr6E1/MAJoEzvpU52XkLoNqhGlVXS8ydgQmoyrRhhDY2nax3 05og== X-Gm-Message-State: AOAM5301fbINdVtSgZ8DTQapGlXTD1ZwAmsgetkMBco1Ev5QRBS+m+Es O2p7dSLIzMrcuHm/v1tl4rsjS0lbQ7fZqsVBzmE= X-Google-Smtp-Source: ABdhPJyGccl/MxvPYFv94N64tpHzvdf+wemuyQg4oLb42ncCO5h288E18XUldsPNcR5R1wmjJ+1/STDMJze9V26YRWk= X-Received: by 2002:a2e:b8cb:: with SMTP id s11mr57469ljp.110.1597250437831; Wed, 12 Aug 2020 09:40:37 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> In-Reply-To: <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> From: Dick Hardt Date: Wed, 12 Aug 2020 09:40:00 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6dfeb05acb0d8bb" Archived-At: Subject: Re: [GNAP] Terminology 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: Wed, 12 Aug 2020 16:40:46 -0000 --000000000000f6dfeb05acb0d8bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is being granted is whatever is being negotiated between the Grant Server and the Grant Client -> Which fits into the name of the WG, Grant Negotiation and Authorization Protocol, allows us to have names that are specific and precise for the roles (Grant Server and Grant Client rather than Requesting Party), and is usable by an extension that wants to negotiate some new thing between the two roles. I introduced the term "Grant" in XAuth to mean what the client requested, and what the "server" provided, which included both resource access and identity claims. You are narrowly defining grant to ONLY mean "access to something". Sometimes I think you just want to disagree with me. :) I'd be interested in hearing from others! In the current drafts, that is resource access and identity claims. =E1=90=A7 On Wed, Aug 12, 2020 at 8:58 AM Justin Richer wrote: > What is being granted is access to something. This makes sense in terms o= f > rights bound to an access token, but I would argue it makes less sense fo= r > things returned directly. > > Since you and I also disagree on whether returning things directly is an > important distinction (even though both the XAuth and XYZ proposals make > this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d want= to extend the > notion of =E2=80=9Cgrant=E2=80=9D to include anything and everything in t= he request and > response. > > I am arguing for it being more specific and precise. > > =E2=80=94 Justin > > On Aug 11, 2020, at 6:08 PM, Dick Hardt wrote: > > A grant is whatever the client is asking from the server. Currently we > have access to resources and identity claims. It could contain anything > else an extension adds that a client may request from a server. > > Given the definition of grant that I included, why is grant not the right > term to use for this? > > > On Tue, Aug 11, 2020 at 1:35 PM Justin Richer wrote: > >> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said t= hat your >> definition of it was problematic. Namely, the desire to lump in claims >> about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. >> >> =E2=80=94 Justin >> >> On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: >> >> I agree that orchestrator may be a role in the protocol -- it is not a >> role in XYZ or XAuth today. >> >> Justin: would you explain why you think the term "grant" is problematic? >> It is in the WG name! >> >> The client is receiving more than access to resources from the GS, it is >> also receiving claims, so "client of the resource" is too limiting. >> >> Reading the definition of grant[1], it fits as a verb of what the GS is >> doing, and fits as a noun of what the GS provides to the client. >> >> A Grant Server is an Authorization Server in OAuth, and an OpenID >> Provider in OpenID Connect. >> The Grant Client is a Client in OAuth, and a Relying Party in OpenID >> Connect. >> >> Having new terms (GS and GC) in GNAP, separating the roles from OAuth an= d >> OpenID Connect. >> It is straightforward to know what a GC and GS do when you understand >> that a grant is a combination of resource access (from OAuth) and claims >> (from OpenID Connect). >> >> /Dick >> >> [1] https://www.dictionary.com/browse/grant >> verb (used with object) >> to bestow or confer, especially by a formal act:to grant a charter. >> to give or accord:to grant permission. >> to agree or accede to:to grant a request. >> to admit or concede; accept for the sake of argument:I grant that point. >> SEE MORE >> noun >> something granted, as a privilege or right, a sum of money, or a tract o= f >> land:Several major foundations made large grants to fund the research >> project. >> the act of granting. >> >> >> [1] >> >> >> >> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote: >> >>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the = classical >>> =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2= =80=9Corchestrator=E2=80=9D fits with the >>> =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been brought up her= e before, so I=E2=80=99m inclined to >>> believe it can be a separate role from the client. >>> >>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as = it is not a >>> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of t= he resource=E2=80=9D. >>> >>> I also think it=E2=80=99s problematic to lump in user claims with a =E2= =80=9Cgrant=E2=80=9D and >>> that=E2=80=99s just going to muddle everything. >>> >>> =E2=80=94 Justin >>> >>> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >>> >>> I echo Mike's comments on preserving names when possible. The shift fro= m >>> "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >>> >>> I also echo Tom's comments about separating Entities from Roles. >>> >>> Orchestration[1] in my opinion is not what the "client" is doing. >>> >>> Below is a stab at separating the entities and the roles >>> >>> /Dick >>> >>> *Tl;dr: * >>> - Client -> Grant Client >>> - added Relying Party, Claims Issuer, and Grant Server Operator as >>> entities >>> >>> *Roles* - parties to the protocol >>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>> >>> *Entities* - parties to a Trust Framework >>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operator >>> (GSO), Resource Owner (RO) >>> >>> *Grant *- may contain claims and/or access to resources >>> >>> *#Protocol Roles* >>> >>> *Grant Client* (GC) >>> - used by User >>> - operated / provided by RP >>> - requests Grants from the GS >>> - access resources at an RS >>> - consumes Claims >>> >>> *Grant Server* (GS) >>> - operated by GSO >>> - may interact with the User >>> - may interact with the RO >>> - accepts grant requests from GCs >>> - issues grants to GCs >>> - may issue claims >>> >>> *Resource Server* (RS) >>> - manages access to resources for the RO >>> - provides access to resources for the GC >>> - accepts access granted by the GS >>> >>> *#Legal Entities* >>> >>> *User* >>> - uses Grant Client >>> - may interact with the Grant Server >>> - may also be a RO >>> - trusts RP, Issuer, GSO >>> >>> *Relying Party* (RP) >>> - provides Grant Client to the User. >>> - may trust Issuers, GSOs, and ROs >>> >>> *Claims Issuer* (Issuer) >>> - issues claims to RP >>> - may use GS or RS to issue claims >>> >>> *Grant Server Operator* (GSO) >>> - operates the GS >>> - trusted by User, RP, and RO >>> - may also be an Issuer >>> >>> *Resource Owne*r (RO) >>> - owns resources at the RS >>> - trusts GSO to control access to the resources >>> - may be same entity as the User >>> - may also be an Issuer >>> >>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >>> >>> Orchestration (computing) >>> From Wikipedia, the free encyclopedia >>> Jump to navigation >>> Jump >>> to search >>> >>> In system administration >>> , *orchestration* = is >>> the automated configuration >>> , coordination, >>> and management of computer systems and software >>> .[1] >>> >>> A number of tools exist >>> for >>> automation of server configuration and management, including Ansible >>> , Puppet >>> , Salt >>> , Terraform >>> ,[2] >>> >>> and AWS CloudFormation >>> .[3] >>> >>> Usage[edit >>> >>> ] >>> Orchestration is often discussed in the context of service-oriented >>> architecture >>> , >>> virtualization , >>> provisioning , converged >>> infrastructure = and >>> dynamic datacenter topics. >>> Orchestration in this sense is about aligning the business request with= the >>> applications, data, and infrastructure.[4] >>> >>> In the context of cloud computing >>> , the main difference >>> between workflow automation >>> and orchestration >>> is that workflows are processed and completed as processes within a sin= gle >>> domain for automation purposes, whereas orchestration includes a workfl= ow >>> and provides a directed action towards larger goals and objectives.[1] >>> >>> In this context, and with the overall aim to achieve specific goals and >>> objectives (described through quality of service >>> parameters), for >>> example, meet application performance goals using minimized cost[5] >>> and >>> maximize application performance within budget constraints.[6] >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones >>> wrote: >>> >>>> One of the things that people hated about OAuth was it invented new >>>> terminology that wasn=E2=80=99t in common use. But for better or for = worse, the >>>> terms Client, Authorization Server, and Protected Resource are now wid= ely >>>> understood. >>>> >>>> >>>> >>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even mo= re novel >>>> terms, when existing terms will fit the bill. Client wasn=E2=80=99t a= perfect >>>> choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary men= agerie would >>>> definitely make things worse. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* TXAuth *On Behalf Of *Tom Jones >>>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>>> *To:* Dave Tonge >>>> *Cc:* Francis Pouatcha ; Justin Richer ; >>>> Dick Hardt ; Benjamin Kaduk ; >>>> Fabien Imbault ; Denis ; >>>> txauth@ietf.org >>>> *Subject:* Re: [GNAP] Terminology >>>> >>>> >>>> >>>> the term "orchestator" does not match any use case i have. >>>> >>>> Let's be clear that there are four entities to a single transaction in >>>> the real world sense of things. (and others that support the transact= ion.) >>>> >>>> Then we can focus on the end point roles. I will focus on the data >>>> privacy issues, API's have the same parties with different terminology= . >>>> >>>> 1. the subject of the data to be transferred. >>>> >>>> 2. the user of a grant from the subject to act as delegate. (see >>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the >>>> user) >>>> >>>> 3. the site that has a repository of user data with legal obligations >>>> to protect that data (the GDPR) (role resource server.) >>>> >>>> 4 the site that wants either access to the data, or some privacy >>>> preserving statement about the existence and content of the data. (rol= e of >>>> client, vendor, PISP, etc.) >>>> >>>> 5. some sorts of facilitator sites for allowing access (roles like >>>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been= left >>>> out of OAUTH for good reason. >>>> >>>> >>>> >>>> This is a note supporting the separation of roles from legal entities. >>>> BTW, I firmly believe that the legal entity also needs to be ID'd by t= he >>>> transaction. >>>> >>>> Peace ..tom >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>>> wrote: >>>> >>>> Hi all >>>> >>>> >>>> >>>> I agree that "client" can be confusing. I would be in support of >>>> alternative terminology. >>>> >>>> We can always have some wording that explains that an "Orchestrator" i= n >>>> GNAP plays a similar role to "Client" in OAuth. >>>> >>>> >>>> >>>> Dave >>>> >>>> >>>> >>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault >>>> wrote: >>>> >>>> Hi Francis, >>>> >>>> >>>> >>>> I like your proposal, seems much more intuitive. >>>> >>>> >>>> >>>> Fabien >>>> >>>> >>>> >>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>>> =C3=A9crit : >>>> >>>> Hello Denis, Justin, Dick, Fabien, >>>> >>>> >>>> >>>> In this post ( >>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOG= Nw/) >>>> i suggested we use the word "Orchestrator" to designate the piece of >>>> software that orchestrate interaction between "Requestor" (a.k.a. User= ), AS >>>> and RS to obtain the protected resource. >>>> >>>> >>>> >>>> We are turning around the same topic. As soon as we go beyond the >>>> original oAuth protocol, the word 'Client' becomes confusing. >>>> >>>> >>>> >>>> In the same response, I suggest we talk about "roles" and not >>>> "entities". >>>> >>>> >>>> >>>> Best regards. >>>> >>>> /Francis >>>> >>>> >>>> >>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote= : >>>> >>>> I still think that client was the right name in OAuth 2, as the client >>>> wanted to do a client-server interaction, so the client used OAuth 2 t= o get >>>> an access token to interact with the "server". >>>> >>>> >>>> >>>> I do agree that it is not the best term in GNAP. Primarily because GNA= P >>>> is a combination of the client from OAuth 2, and the relying party fro= m >>>> OIDC. >>>> >>>> >>>> >>>> /Dick >>>> >>>> =E1=90=A7 >>>> >>>> >>>> >>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: >>>> >>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>>> >>>> >>>> >>>> The term client in OAuth came from the computer science definition of >>>> client-server interaction. >>>> >>>> >>>> >>>> This, I would argue, is exactly why it=E2=80=99s a bad label for somet= hing >>>> that=E2=80=99s distinctly more specific in this context, and I would l= ove to see >>>> GNAP adopt a more specific label for the role that we traditionally ca= lled >>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> >>>> >>>> The client is getting an access token so it can call a server, >>>> specifically, a resource server (to differentiate it from the authoriz= ation >>>> server). >>>> >>>> >>>> >>>> The confusion in my experience usually stems from people working with >>>> software that is acting in multiple roles. IE, the software that is ac= ting >>>> as a client in once context, is also acting as an RS in other contexts= , or >>>> even acting as an AS. The other confusion is that people view clients = as >>>> being the software the user is using -- although it may not be acting = as a >>>> client in the oauth context. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> >>>> >>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault >>>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> To me, client has always been a strange word in the context of OAuth, >>>> as it has a meaning well defined both in everyday life (this client is= a >>>> good customer) and in computer science (client-server interaction). Th= us I >>>> always have to make the mental translation to the OAuth world before a= ny >>>> discussion... And any teaching experience shows that it does make the >>>> concepts hard to grasp for a majority of (clever) people. >>>> >>>> >>>> >>>> As for the RO, previous discussions suggested Resource >>>> Controller (RC) also, which may be a bit more specific than manager. >>>> >>>> >>>> >>>> Fabien >>>> >>>> >>>> >>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>> >>>> Justin and Dick, >>>> >>>> >>>> >>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>> the creation of OAuth)"] >>>> >>>> >>>> >>>> So let us attempt to define new terms: >>>> >>>> *initiating application (IA)*: application by means of which a user >>>> initiates interactions with RS(s) and AS(s) >>>> >>>> In the same way, we should get rid of the term Resource Owner (RO), >>>> which is currently defined as: >>>> >>>> Resource Owner (RO): entity capable of granting access to a protected >>>> resource >>>> >>>> I propose to replace it with Resource Manager (RM): >>>> >>>> *Resource Manager (RM)* : application or user that manages an access >>>> decision function of a Resource Server >>>> >>>> Denis >>>> >>>> >>>> >>>> I agree with Justin. Redefining well used terms will lead to >>>> significant confusion. If we have a different role than what we have h= ad >>>> in the past, then that role should have a name not being used already = in >>>> OAuth or OIDC. >>>> >>>> >>>> >>>> Given what we have learned, and my own experience explaining what a >>>> Client is, and is not, improving the definition for Client could prove >>>> useful. I am not suggesting the term be redefined, but clarified. >>>> >>>> >>>> >>>> For example, clarifying that a Client is a role an entity plays in the >>>> protocol, and that the same entity may play other roles at other times= , or >>>> some other language to help differentiate between "role" and "entity". >>>> >>>> >>>> >>>> /Dick >>>> >>>> =E1=90=A7 >>>> >>>> >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>>> >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bet= ter fit, but I=E2=80=99m >>>> not really in favor of taking an existing term and applying a complete= ly >>>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>>> and come up with a new, more specific and accurate term for the role t= han >>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely dif= ferent. We did this >>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserve= r=E2=80=9D on its own but instead >>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>> >>>> >>>> >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is >>>> ignore the fact that GNAP is going to be coming up in a world that is >>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t ha= ve a blank >>>> slate to work with, but neither are we bound to use the same terms and >>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>> >>>> >>>> >>>> I think that is fundamentally part of the question: >>>> >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion >>>> >>>> >>>> >>>> If we say that this document assumes OAuth2.0 terminology, then we >>>> should not change the meanings of any definition. If we are saying thi= s >>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the= best >>>> word for the job and ignore conflicting meanings from OAuth 2.0. I hav= e a >>>> lot of first hand experience of industries "ruining words", and attemp= ting >>>> to side-step the problem rather than redefining the word just confuses >>>> everyone as everyone forgets the original meaning as new documents com= e >>>> out, but the confusion with the use of a non-obvious word continues. >>>> >>>> >>>> >>>> Food for thought. >>>> >>>> - Warren >>>> >>>> >>>> *Warren Parad* >>>> >>>> Founder, CTO >>>> >>>> Secure your user data and complete your authorization architecture. >>>> Implement Authress . >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>> >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a response similar to the >>>> one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in us= e here. >>>> What >>>> > > you describe as RS2, which might in fact be an RS unto itself, is = a >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client= of RS1/. What >>>> you >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world= , but it is not >>>> at >>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>> > > entities below, but it makes it difficult to hold a discussion if >>>> we >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can >>>> define >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>> definitions, >>>> > > but we=E2=80=99ve got a chance to be more precise with how we defi= ne things. >>>> > >>>> > In the ISO context, each document must define its own terminology. >>>> The >>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>> section >>>> > but does not prevent it either. The vocabulary is limited and as lon= g >>>> as >>>> > we clearly define what our terms are meaning, we can re-use a term >>>> already >>>> > used in another RFC. This is also the ISO approach. >>>> >>>> Just because we can do something does not necessarily mean that it is = a >>>> good idea to do so. We are clear that we are producing a protocol tha= t >>>> is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted >>>> Dick to >>>> use the term "GS" in XAuth, picking a name that was not already used i= n >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> -- >>>> 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/ >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>>> >>>> >>>> *Moneyhub Enterprise is a trading style of Moneyhub Financial >>>> Technology Limited which is authorised and regulated by the Financial >>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on= the >>>> Financial Services Register (FRN 809360) at https://register.fca.org.u= k/ >>>> . Moneyhub Financial Technology is regis= tered >>>> in England & Wales, company registration number 06909772. Moneyhub >>>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Bu= ilding, >>>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>> >> > --000000000000f6dfeb05acb0d8bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is being granted is whatever is being negotiated betw= een the Grant Server and the Grant Client -> Which fits into the name of= the WG, Grant Negotiation and Authorization Protocol, allows us to have na= mes that are specific and precise for the roles (Grant Server and Grant Cli= ent rather than Requesting Party), and is usable by an extension that wants= to negotiate some new thing between the two roles.=C2=A0

I introduced the term "Grant" in XAuth to mean what the client = requested, and what the "server" provided, which included both re= source access and identity claims. You are narrowly defining grant to ONLY = mean "access to something". Sometimes I think you just want to di= sagree with me. :)

I'd be interested in hearin= g from others!



=
In the current drafts, that is resource access and identity clai= ms.=C2=A0

3D""=E1=90=A7
On Wed, = Aug 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
What is being gr= anted is access to something. This makes sense in terms of rights bound to = an access token, but I would argue it makes less sense for things returned = directly.

Since you and I also disagree on whether retur= ning things directly is an important distinction (even though both the XAut= h and XYZ proposals make this distinction), it doesn=E2=80=99t surprise me = that you=E2=80=99d want to extend the notion of =E2=80=9Cgrant=E2=80=9D to = include anything and everything in the request and response.=C2=A0

I am arguing for it being more specific and precise.
=

=C2=A0=E2=80=94 Justin

On Aug 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
A grant is whatever the client is asking from= the server. Currently we have access to resources and identity claims. It = could contain anything else an extension adds that a client may request fro= m a server.

Given the definition of grant that I include= d, why is grant not the right term to use for this?


On = Tue, Aug 11, 2020 at 1:35 PM Justin Richer <jricher@mit.edu> wrote:
I did not say the term =E2=80= =9Cgrant=E2=80=9D was problematic, I said that your definition of it was pr= oblematic. Namely, the desire to lump in claims about the user into the def= inition of the =E2=80=9Cgrant=E2=80=9D.=C2=A0

=C2=A0=E2= =80=94 Justin

On Aug 11, 2020, a= t 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be a role in the protocol -- it is not a rol= e in XYZ or XAuth today.

Justin: would you explain why y= ou think the term "grant" is problematic? It is in the WG name!

The client is receiving=C2=A0more than access to re= sources from the GS, it is also receiving=C2=A0claims, so "client of t= he resource" is too limiting.

Reading the def= inition of grant[1], it fits as a verb of what the GS is doing, and fits as= a noun of what the GS provides to the client.

A G= rant Server is an Authorization Server in OAuth, and an OpenID Provider in = OpenID Connect.
The Grant Client is a Client in OAuth, and a Rely= ing Party in OpenID Connect.

Having new terms (GS = and GC) in GNAP, separating the roles from OAuth and OpenID Connect.
<= div>It is straightforward=C2=A0to know what a GC and GS do when you underst= and that=C2=A0a grant is a combination of resource access (from OAuth) and = claims (from OpenID Connect).

/Dick

=
verb (used with object)=
to bestow or confer, especially by a formal act:to grant a charter.
to give or accord:to grant permission.
to agree or = accede to:to grant a request.
to admit or concede; accept for the sake of argument:I grant that point.

noun

something granted, as a privilege= or right, a sum of money, or a tract of land:Several major foundations made large grants to fund the research project.<= /span>
the act of granting.
<= div>

[1]=C2=A0



On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that =E2=80=9C= orchestration=E2=80=9D is separate from what the classical =E2=80=9Cclient= =E2=80=9D in OAuth is doing =E2=80=94 but the term =E2=80=9Corchestrator=E2= =80=9D fits with the =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s be= en brought up here before, so I=E2=80=99m inclined to believe it can be a s= eparate role from the client.

I personally think that = =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient = of the grant=E2=80=9D but rather a =E2=80=9Cclient of the resource=E2=80=9D= .

I also think it=E2=80=99s problematic to lump in= user claims with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going t= o muddle everything.=C2=A0

=C2=A0=E2=80=94 Justin<= br>

On Aug 11, 2020, at 3:25 PM, Dic= k Hardt <dick.= hardt@gmail.com> wrote:

I echo Mike's comments on preservin= g names when possible. The shift from "consumer" in OAuth 1 to &q= uot;client" in OAuth 2 was confusing to many.

=
I also echo Tom's comments about separating Entities from Roles.

Orchestration[1] in my opinion is not what the &quo= t;client" is doing.

Below is a stab at separa= ting the entities and the roles

/Dick
Tl;dr:=C2=A0
- Client=C2=A0-> Grant Client=
- added Relying Party, Claims Issuer, and Grant Server Operator = as entities

Roles - parties to the pro= tocol
Grant Client (GC), Grant Server (GS), Resource Server (RS)<= /div>

Entities - parties to a Tr= ust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant S= erver Operator (GSO), Resource=C2=A0Owner (RO)
<= br>
Grant -=C2=A0may contain claims and/or access to resou= rces

#Protocol Roles

Grant Client (GC)
- used by User
- operated /= provided by RP
- requests Grants from the GS
- access = resources at an RS
- consumes Claims

= Grant Server (GS)
- operated by GSO
- may interact = with the User=C2=A0
- may interact with the RO
- accept= s grant requests from GCs
- issues grants to GCs
- may= issue claims

Resource Server (RS)
- manages access to resources for the RO
- provides access to r= esources for the GC
- accepts access granted by the GS
=
#Legal Entities

User<= /div>
- uses Grant Client
- may interact with the Grant Serve= r
- may also be a RO
- trusts RP, Issuer, GSO

Relying Party (RP)
- provides Grant Client= to the User.
- may trust Issuers, GSOs, and ROs

<= /div>
Claims Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant= Server Operator (GSO)
- operates the GS
- trusted = by User, RP, and RO
- may also be an Issuer

=
Resource Owner (RO)
- owns resources at the RS<= /div>
- trusts GSO to control access to the resources
- may b= e same entity as the User
- may also be an Issuer
=


Orchestration (computing)

From = Wikipedia, the free encyclopedia
Jump to navigationJump to search
In=C2=A0system administration,=C2=A0orchestration=C2=A0i= s the automated=C2=A0configuratio= n, coordination, and management of computer systems and=C2=A0software.[1]
A=C2=A0number= of tools exist=C2=A0for automation of server configuration and managem= ent, including=C2=A0Ansible,=C2=A0Puppet,=C2=A0Salt,=C2= =A0Terraform,[2]=C2=A0and=C2=A0AWS CloudFormation.[3]

Usage[edit= ]

=
Orchestration is often discussed in the con= text of=C2=A0service-or= iented architecture,=C2=A0virtu= alization,=C2=A0provisioning,=C2=A0converged infrastructure=C2=A0and dynamic= =C2=A0datacenter=C2=A0topics. Orchestration in this sense= is about aligning the business request with the applications, data, and in= frastructure.[4= ]
In the context of=C2=A0cloud computing, the main difference between=C2=A0= workflow automation=C2=A0and orchestrat= ion is that workflows are processed and completed as processes within a sin= gle domain for automation purposes, whereas orchestration includes a workfl= ow and provides a directed action towards larger goals and objectives.[1]
In this context, and with the over= all aim to achieve specific goals and objectives (described through=C2=A0quality of service=C2=A0parameters), for ex= ample, meet application performance goals using minimized cost[5]=C2=A0and maximize application performance within budget c= onstraints.[6]







=

On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@= microsoft.com> wrote:

One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

=C2=A0

Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

= From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match= any use case i have.

Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would = be in support of alternative terminology.

We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive= .=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

=C2=A0

I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1=90=A7<= u>

=C2=A0

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

The term client in OAuth came from the computer= science definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

=C2=A0

The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7<= u>

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

Ju= stin and Dick,

=C2=A0

[W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

=C2=A0

So= let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

Re= source Owner (RO): entity capable of granting access to a protected resourc= e

I = propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

D= enis

=C2=A0

I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

=C2=A0

For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

=C2=A0

/Dick

=E1=90=A7<= u>

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

=C2=A0

I think that is fundamentally part of the quest= ion:

We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warren Parad<= u>

Founder, CTO=

Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

=C2=A0

=C2=A0

Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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




--000000000000f6dfeb05acb0d8bb-- From nobody Wed Aug 12 09:43:51 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 092563A13CC for ; Wed, 12 Aug 2020 09:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 A5LUF-1ovQ9b for ; Wed, 12 Aug 2020 09:43:43 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 950EA3A1154 for ; Wed, 12 Aug 2020 09:43:43 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id v6so3424592iow.11 for ; Wed, 12 Aug 2020 09:43:43 -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=rLA7B0ruv8WNQCB5Hx754jSIechYwfrslAPbDUxXShw=; b=my5NcIIWwzknZljEpc8vsHkzR8gVN1SKW6EpIomWY6+p/qnEoWgdVLby2hrl1sIgfC yjj9PK5J/RCt4+j58W4GsWyoDEbimh28CV3TZcvCwfOo5O2f0PSC36AIlxlhRUDcyX5l 9CcvyddR5Omnro5Mgifj2VUvAd3DvkHLCyd7ClORM9fgWIrj3LtwbzaW0Tcx1LPGhbJO 7od/iBq3lHRaOSBSYVBU9RGBf+47qp+QOfKeS6CI/xrxSJz96syTxLKohDpsTR00fFak EWo5FipzKNVVzXVMG2SEtRM0dEFdJ41nh7ISx+DKR1GXKvu+nrYImKRtOIlBhm7Jn98D ingg== 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=rLA7B0ruv8WNQCB5Hx754jSIechYwfrslAPbDUxXShw=; b=iK8UBD5QaACD5136kqxyKe+ZO3l5HBe6PhCJkNy/RHr/XVxBsp+vldYBJu1d5m0G0A 86N5ACJmfNfGuXY9TNyNHQvVeRKfuS2+iwuBBZrQJf3E23pT7euzeFGdtSH20g7yriD3 PQcVM4QYOlTXSdrY0bmvvA72Bj2H7BzggQFI6E/nli1PB64NraIZ4mpXmsHd/aAgq7dq Dx9qfwwg2q2e4qMSU24LXo771xDlUwu41lkek1BOs1liF3P0SceWalOUX2HzEvyMyhvw tnIMIhuwQnhjuu0sX6ZqDzk5OZdH/Q+Qka8HwG+rqzlV2gnYjcSKVKPs5Hgei06JOl0L 1Phg== X-Gm-Message-State: AOAM530w0bYi/VC8Qm9Ou0jkqoz8amcKJTcJ/EJcksvF06uO1p/sEgCg uWxQTV2JOcE+ekTP/Q+uMC8s3+rwTySu0dAvgeE= X-Google-Smtp-Source: ABdhPJwlWSE0ddJ9oUJczzvLGauWtrXva163jLv1dXIaAeGEIrkc+Xd89r858Xl6u+DA93+FksEiCr1B98Dz0Cvijzc= X-Received: by 2002:a5d:8041:: with SMTP id b1mr680742ior.74.1597250622793; Wed, 12 Aug 2020 09:43:42 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 12 Aug 2020 18:43:31 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fd2d5b05acb0e3ba" Archived-At: Subject: Re: [GNAP] Terminology 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: Wed, 12 Aug 2020 16:43:49 -0000 --000000000000fd2d5b05acb0e3ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, Maybe to make that discussion more concrete, what else do you imagine could be exchanged (beyond resource & idclaims)? A few examples? Cheers Fabien On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt wrote: > What is being granted is whatever is being negotiated between the Grant > Server and the Grant Client -> Which fits into the name of the WG, Grant > Negotiation and Authorization Protocol, allows us to have names that are > specific and precise for the roles (Grant Server and Grant Client rather > than Requesting Party), and is usable by an extension that wants to > negotiate some new thing between the two roles. > > I introduced the term "Grant" in XAuth to mean what the client requested, > and what the "server" provided, which included both resource access and > identity claims. You are narrowly defining grant to ONLY mean "access to > something". Sometimes I think you just want to disagree with me. :) > > I'd be interested in hearing from others! > > > > In the current drafts, that is resource access and identity claims. > > =E1=90=A7 > > On Wed, Aug 12, 2020 at 8:58 AM Justin Richer wrote: > >> What is being granted is access to something. This makes sense in terms >> of rights bound to an access token, but I would argue it makes less sens= e >> for things returned directly. >> >> Since you and I also disagree on whether returning things directly is an >> important distinction (even though both the XAuth and XYZ proposals make >> this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d wan= t to extend the >> notion of =E2=80=9Cgrant=E2=80=9D to include anything and everything in = the request and >> response. >> >> I am arguing for it being more specific and precise. >> >> =E2=80=94 Justin >> >> On Aug 11, 2020, at 6:08 PM, Dick Hardt wrote: >> >> A grant is whatever the client is asking from the server. Currently we >> have access to resources and identity claims. It could contain anything >> else an extension adds that a client may request from a server. >> >> Given the definition of grant that I included, why is grant not the righ= t >> term to use for this? >> >> >> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer wrote: >> >>> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said = that your >>> definition of it was problematic. Namely, the desire to lump in claims >>> about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. >>> >>> =E2=80=94 Justin >>> >>> On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: >>> >>> I agree that orchestrator may be a role in the protocol -- it is not a >>> role in XYZ or XAuth today. >>> >>> Justin: would you explain why you think the term "grant" is problematic= ? >>> It is in the WG name! >>> >>> The client is receiving more than access to resources from the GS, it i= s >>> also receiving claims, so "client of the resource" is too limiting. >>> >>> Reading the definition of grant[1], it fits as a verb of what the GS is >>> doing, and fits as a noun of what the GS provides to the client. >>> >>> A Grant Server is an Authorization Server in OAuth, and an OpenID >>> Provider in OpenID Connect. >>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID >>> Connect. >>> >>> Having new terms (GS and GC) in GNAP, separating the roles from OAuth >>> and OpenID Connect. >>> It is straightforward to know what a GC and GS do when you understand >>> that a grant is a combination of resource access (from OAuth) and claim= s >>> (from OpenID Connect). >>> >>> /Dick >>> >>> [1] https://www.dictionary.com/browse/grant >>> verb (used with object) >>> to bestow or confer, especially by a formal act:to grant a charter. >>> to give or accord:to grant permission. >>> to agree or accede to:to grant a request. >>> to admit or concede; accept for the sake of argument:I grant that point= . >>> SEE MORE >>> noun >>> something granted, as a privilege or right, a sum of money, or a tract >>> of land:Several major foundations made large grants to fund the >>> research project. >>> the act of granting. >>> >>> >>> [1] >>> >>> >>> >>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote: >>> >>>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the= classical >>>> =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2= =80=9Corchestrator=E2=80=9D fits with the >>>> =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been brought up he= re before, so I=E2=80=99m inclined to >>>> believe it can be a separate role from the client. >>>> >>>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as= it is not a >>>> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of = the resource=E2=80=9D. >>>> >>>> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D and >>>> that=E2=80=99s just going to muddle everything. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >>>> >>>> I echo Mike's comments on preserving names when possible. The shift >>>> from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to man= y. >>>> >>>> I also echo Tom's comments about separating Entities from Roles. >>>> >>>> Orchestration[1] in my opinion is not what the "client" is doing. >>>> >>>> Below is a stab at separating the entities and the roles >>>> >>>> /Dick >>>> >>>> *Tl;dr: * >>>> - Client -> Grant Client >>>> - added Relying Party, Claims Issuer, and Grant Server Operator as >>>> entities >>>> >>>> *Roles* - parties to the protocol >>>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>> >>>> *Entities* - parties to a Trust Framework >>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server Operato= r >>>> (GSO), Resource Owner (RO) >>>> >>>> *Grant *- may contain claims and/or access to resources >>>> >>>> *#Protocol Roles* >>>> >>>> *Grant Client* (GC) >>>> - used by User >>>> - operated / provided by RP >>>> - requests Grants from the GS >>>> - access resources at an RS >>>> - consumes Claims >>>> >>>> *Grant Server* (GS) >>>> - operated by GSO >>>> - may interact with the User >>>> - may interact with the RO >>>> - accepts grant requests from GCs >>>> - issues grants to GCs >>>> - may issue claims >>>> >>>> *Resource Server* (RS) >>>> - manages access to resources for the RO >>>> - provides access to resources for the GC >>>> - accepts access granted by the GS >>>> >>>> *#Legal Entities* >>>> >>>> *User* >>>> - uses Grant Client >>>> - may interact with the Grant Server >>>> - may also be a RO >>>> - trusts RP, Issuer, GSO >>>> >>>> *Relying Party* (RP) >>>> - provides Grant Client to the User. >>>> - may trust Issuers, GSOs, and ROs >>>> >>>> *Claims Issuer* (Issuer) >>>> - issues claims to RP >>>> - may use GS or RS to issue claims >>>> >>>> *Grant Server Operator* (GSO) >>>> - operates the GS >>>> - trusted by User, RP, and RO >>>> - may also be an Issuer >>>> >>>> *Resource Owne*r (RO) >>>> - owns resources at the RS >>>> - trusts GSO to control access to the resources >>>> - may be same entity as the User >>>> - may also be an Issuer >>>> >>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >>>> >>>> Orchestration (computing) >>>> From Wikipedia, the free encyclopedia >>>> Jump to navigation >>>> Jump >>>> to search >>>> >>>> In system administration >>>> , *orchestration*= is >>>> the automated configuration >>>> , >>>> coordination, and management of computer systems and software >>>> .[1] >>>> >>>> A number of tools exist >>>> for >>>> automation of server configuration and management, including Ansible >>>> , Puppet >>>> , Salt >>>> , Terraform >>>> ,[2] >>>> >>>> and AWS CloudFormation >>>> .[3] >>>> >>>> Usage[edit >>>> >>>> ] >>>> Orchestration is often discussed in the context of service-oriented >>>> architecture >>>> , >>>> virtualization >>>> , provisioning , converged >>>> infrastructure and >>>> dynamic datacenter topics. >>>> Orchestration in this sense is about aligning the business request wit= h the >>>> applications, data, and infrastructure.[4] >>>> >>>> In the context of cloud computing >>>> , the main difference >>>> between workflow automation >>>> and orchestration >>>> is that workflows are processed and completed as processes within a si= ngle >>>> domain for automation purposes, whereas orchestration includes a workf= low >>>> and provides a directed action towards larger goals and objectives.[1] >>>> >>>> In this context, and with the overall aim to achieve specific goals an= d >>>> objectives (described through quality of service >>>> parameters), for >>>> example, meet application performance goals using minimized cost[5] >>>> and >>>> maximize application performance within budget constraints.[6] >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones >>>> wrote: >>>> >>>>> One of the things that people hated about OAuth was it invented new >>>>> terminology that wasn=E2=80=99t in common use. But for better or for= worse, the >>>>> terms Client, Authorization Server, and Protected Resource are now wi= dely >>>>> understood. >>>>> >>>>> >>>>> >>>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even m= ore novel >>>>> terms, when existing terms will fit the bill. Client wasn=E2=80=99t = a perfect >>>>> choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary me= nagerie would >>>>> definitely make things worse. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* TXAuth *On Behalf Of *Tom Jones >>>>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>>>> *To:* Dave Tonge >>>>> *Cc:* Francis Pouatcha ; Justin Richer < >>>>> jricher@mit.edu>; Dick Hardt ; Benjamin Kaduk < >>>>> kaduk@mit.edu>; Fabien Imbault ; Denis < >>>>> denis.ietf@free.fr>; txauth@ietf.org >>>>> *Subject:* Re: [GNAP] Terminology >>>>> >>>>> >>>>> >>>>> the term "orchestator" does not match any use case i have. >>>>> >>>>> Let's be clear that there are four entities to a single transaction i= n >>>>> the real world sense of things. (and others that support the transac= tion.) >>>>> >>>>> Then we can focus on the end point roles. I will focus on the data >>>>> privacy issues, API's have the same parties with different terminolog= y. >>>>> >>>>> 1. the subject of the data to be transferred. >>>>> >>>>> 2. the user of a grant from the subject to act as delegate. (see >>>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable >>>>> the user) >>>>> >>>>> 3. the site that has a repository of user data with legal obligations >>>>> to protect that data (the GDPR) (role resource server.) >>>>> >>>>> 4 the site that wants either access to the data, or some privacy >>>>> preserving statement about the existence and content of the data. (ro= le of >>>>> client, vendor, PISP, etc.) >>>>> >>>>> 5. some sorts of facilitator sites for allowing access (roles like >>>>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have bee= n left >>>>> out of OAUTH for good reason. >>>>> >>>>> >>>>> >>>>> This is a note supporting the separation of roles from legal >>>>> entities. BTW, I firmly believe that the legal entity also needs to = be >>>>> ID'd by the transaction. >>>>> >>>>> Peace ..tom >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>>>> wrote: >>>>> >>>>> Hi all >>>>> >>>>> >>>>> >>>>> I agree that "client" can be confusing. I would be in support of >>>>> alternative terminology. >>>>> >>>>> We can always have some wording that explains that an "Orchestrator" >>>>> in GNAP plays a similar role to "Client" in OAuth. >>>>> >>>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault >>>>> wrote: >>>>> >>>>> Hi Francis, >>>>> >>>>> >>>>> >>>>> I like your proposal, seems much more intuitive. >>>>> >>>>> >>>>> >>>>> Fabien >>>>> >>>>> >>>>> >>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>>>> =C3=A9crit : >>>>> >>>>> Hello Denis, Justin, Dick, Fabien, >>>>> >>>>> >>>>> >>>>> In this post ( >>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JO= GNw/) >>>>> i suggested we use the word "Orchestrator" to designate the piece of >>>>> software that orchestrate interaction between "Requestor" (a.k.a. Use= r), AS >>>>> and RS to obtain the protected resource. >>>>> >>>>> >>>>> >>>>> We are turning around the same topic. As soon as we go beyond the >>>>> original oAuth protocol, the word 'Client' becomes confusing. >>>>> >>>>> >>>>> >>>>> In the same response, I suggest we talk about "roles" and not >>>>> "entities". >>>>> >>>>> >>>>> >>>>> Best regards. >>>>> >>>>> /Francis >>>>> >>>>> >>>>> >>>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt >>>>> wrote: >>>>> >>>>> I still think that client was the right name in OAuth 2, as the clien= t >>>>> wanted to do a client-server interaction, so the client used OAuth 2 = to get >>>>> an access token to interact with the "server". >>>>> >>>>> >>>>> >>>>> I do agree that it is not the best term in GNAP. Primarily because >>>>> GNAP is a combination of the client from OAuth 2, and the relying par= ty >>>>> from OIDC. >>>>> >>>>> >>>>> >>>>> /Dick >>>>> >>>>> =E1=90=A7 >>>>> >>>>> >>>>> >>>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote= : >>>>> >>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: >>>>> >>>>> >>>>> >>>>> The term client in OAuth came from the computer science definition of >>>>> client-server interaction. >>>>> >>>>> >>>>> >>>>> This, I would argue, is exactly why it=E2=80=99s a bad label for some= thing >>>>> that=E2=80=99s distinctly more specific in this context, and I would = love to see >>>>> GNAP adopt a more specific label for the role that we traditionally c= alled >>>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>>> >>>>> >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The client is getting an access token so it can call a server, >>>>> specifically, a resource server (to differentiate it from the authori= zation >>>>> server). >>>>> >>>>> >>>>> >>>>> The confusion in my experience usually stems from people working with >>>>> software that is acting in multiple roles. IE, the software that is a= cting >>>>> as a client in once context, is also acting as an RS in other context= s, or >>>>> even acting as an AS. The other confusion is that people view clients= as >>>>> being the software the user is using -- although it may not be acting= as a >>>>> client in the oauth context. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =E1=90=A7 >>>>> >>>>> >>>>> >>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> To me, client has always been a strange word in the context of OAuth, >>>>> as it has a meaning well defined both in everyday life (this client i= s a >>>>> good customer) and in computer science (client-server interaction). T= hus I >>>>> always have to make the mental translation to the OAuth world before = any >>>>> discussion... And any teaching experience shows that it does make the >>>>> concepts hard to grasp for a majority of (clever) people. >>>>> >>>>> >>>>> >>>>> As for the RO, previous discussions suggested Resource >>>>> Controller (RC) also, which may be a bit more specific than manager. >>>>> >>>>> >>>>> >>>>> Fabien >>>>> >>>>> >>>>> >>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>>> >>>>> Justin and Dick, >>>>> >>>>> >>>>> >>>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>>> the creation of OAuth)"] >>>>> >>>>> >>>>> >>>>> So let us attempt to define new terms: >>>>> >>>>> *initiating application (IA)*: application by means of which a user >>>>> initiates interactions with RS(s) and AS(s) >>>>> >>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>> which is currently defined as: >>>>> >>>>> Resource Owner (RO): entity capable of granting access to a protected >>>>> resource >>>>> >>>>> I propose to replace it with Resource Manager (RM): >>>>> >>>>> *Resource Manager (RM)* : application or user that manages an access >>>>> decision function of a Resource Server >>>>> >>>>> Denis >>>>> >>>>> >>>>> >>>>> I agree with Justin. Redefining well used terms will lead to >>>>> significant confusion. If we have a different role than what we have = had >>>>> in the past, then that role should have a name not being used already= in >>>>> OAuth or OIDC. >>>>> >>>>> >>>>> >>>>> Given what we have learned, and my own experience explaining what a >>>>> Client is, and is not, improving the definition for Client could prov= e >>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>> >>>>> >>>>> >>>>> For example, clarifying that a Client is a role an entity plays in th= e >>>>> protocol, and that the same entity may play other roles at other time= s, or >>>>> some other language to help differentiate between "role" and "entity"= . >>>>> >>>>> >>>>> >>>>> /Dick >>>>> >>>>> =E1=90=A7 >>>>> >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: >>>>> >>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a be= tter fit, but I=E2=80=99m >>>>> not really in favor of taking an existing term and applying a complet= ely >>>>> new definition to it. In other words, I would sooner stop using =E2= =80=9Cclient=E2=80=9D >>>>> and come up with a new, more specific and accurate term for the role = than >>>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely di= fferent. We did this >>>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserv= er=E2=80=9D on its own but instead >>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>> >>>>> >>>>> >>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>> ignore the fact that GNAP is going to be coming up in a world that is >>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t h= ave a blank >>>>> slate to work with, but neither are we bound to use the same terms an= d >>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>> >>>>> >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> >>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>> >>>>> >>>>> >>>>> I think that is fundamentally part of the question: >>>>> >>>>> We are clear that we are producing a protocol that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion >>>>> >>>>> >>>>> >>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>> should not change the meanings of any definition. If we are saying th= is >>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick th= e best >>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I ha= ve a >>>>> lot of first hand experience of industries "ruining words", and attem= pting >>>>> to side-step the problem rather than redefining the word just confuse= s >>>>> everyone as everyone forgets the original meaning as new documents co= me >>>>> out, but the confusion with the use of a non-obvious word continues. >>>>> >>>>> >>>>> >>>>> Food for thought. >>>>> >>>>> - Warren >>>>> >>>>> >>>>> *Warren Parad* >>>>> >>>>> Founder, CTO >>>>> >>>>> Secure your user data and complete your authorization architecture. >>>>> Implement Authress . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>>> >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a response similar to th= e >>>>> one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there=E2=80=99s still a problem with the terminology in u= se here. >>>>> What >>>>> > > you describe as RS2, which might in fact be an RS unto itself, is >>>>> a >>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What >>>>> you >>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not >>>>> at >>>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>>> > > entities below, but it makes it difficult to hold a discussion if >>>>> we >>>>> > > aren=E2=80=99t using the same terms. >>>>> > > >>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can >>>>> define >>>>> > > our own terms. The bad news is that this is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>>> definitions, >>>>> > > but we=E2=80=99ve got a chance to be more precise with how we def= ine >>>>> things. >>>>> > >>>>> > In the ISO context, each document must define its own terminology. >>>>> The >>>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>>> section >>>>> > but does not prevent it either. The vocabulary is limited and as >>>>> long as >>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>> already >>>>> > used in another RFC. This is also the ISO approach. >>>>> >>>>> Just because we can do something does not necessarily mean that it is= a >>>>> good idea to do so. We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>> Dick to >>>>> use the term "GS" in XAuth, picking a name that was not already used = in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> >>>>> -- >>>>> 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/ >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at https://register.fca.org.= uk/ >>>>> . Moneyhub Financial Technology is regi= stered >>>>> in England & Wales, company registration number 06909772. Moneyhub >>>>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus B= uilding, >>>>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> >>>> >>> >> --000000000000fd2d5b05acb0e3ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,=C2=A0

Maybe to make that discu= ssion more concrete, what else do you imagine could be exchanged (beyond re= source & idclaims)? A few examples?

Cheers
Fabien=C2=A0



On Wed, Aug 12, 2020= at 6:40 PM Dick Hardt <dick.har= dt@gmail.com> wrote:
What is being granted is whatever is being neg= otiated between the Grant Server and the Grant Client -> Which fits into= the name of the WG, Grant Negotiation and Authorization Protocol, allows u= s to have names that are specific and precise for the roles (Grant Server a= nd Grant Client rather than Requesting Party), and is usable by an extensio= n that wants to negotiate some new thing between the two roles.=C2=A0
<= br>
I introduced the term "Grant" in XAuth to mean what= the client requested, and what the "server" provided, which incl= uded both resource access and identity claims. You are narrowly defining gr= ant to ONLY mean "access to something". Sometimes I think you jus= t want to disagree with me. :)

I'd be interest= ed in hearing from others!



In the current drafts, that is resource access and i= dentity claims.=C2=A0

3D""=E1=90= =A7

On Wed, Aug 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
What is being gra= nted is access to something. This makes sense in terms of rights bound to a= n access token, but I would argue it makes less sense for things returned d= irectly.

Since you and I also disagree on whether return= ing things directly is an important distinction (even though both the XAuth= and XYZ proposals make this distinction), it doesn=E2=80=99t surprise me t= hat you=E2=80=99d want to extend the notion of =E2=80=9Cgrant=E2=80=9D to i= nclude anything and everything in the request and response.=C2=A0

I am arguing for it being more specific and precise.
<= div>
=C2=A0=E2=80=94 Justin

On Aug 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
A grant is whatever the client is asking from = the server. Currently we have access to resources and identity claims. It c= ould contain anything else an extension adds that a client may request from= a server.

Given the definition of grant that I included= , why is grant not the right term to use for this?


On T= ue, Aug 11, 2020 at 1:35 PM Justin Richer <jricher@mit.edu> wrote:
I did not say the term =E2=80= =9Cgrant=E2=80=9D was problematic, I said that your definition of it was pr= oblematic. Namely, the desire to lump in claims about the user into the def= inition of the =E2=80=9Cgrant=E2=80=9D.=C2=A0

=C2=A0=E2= =80=94 Justin

On Aug 11, 2020, a= t 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be a role in the protocol -- it is not a rol= e in XYZ or XAuth today.

Justin: would you explain why y= ou think the term "grant" is problematic? It is in the WG name!

The client is receiving=C2=A0more than access to re= sources from the GS, it is also receiving=C2=A0claims, so "client of t= he resource" is too limiting.

Reading the def= inition of grant[1], it fits as a verb of what the GS is doing, and fits as= a noun of what the GS provides to the client.

A G= rant Server is an Authorization Server in OAuth, and an OpenID Provider in = OpenID Connect.
The Grant Client is a Client in OAuth, and a Rely= ing Party in OpenID Connect.

Having new terms (GS = and GC) in GNAP, separating the roles from OAuth and OpenID Connect.
<= div>It is straightforward=C2=A0to know what a GC and GS do when you underst= and that=C2=A0a grant is a combination of resource access (from OAuth) and = claims (from OpenID Connect).

/Dick

=
verb (used with object)=
to bestow or confer, especially by a formal act:to grant a charter.
to give or accord:to grant permission.
to agree or = accede to:to grant a request.
to admit or concede; accept for the sake of argument:I grant that point.

noun

something granted, as a privilege= or right, a sum of money, or a tract of land:Several major foundations made large grants to fund the research project.<= /span>
the act of granting.
<= div>

[1]=C2=A0



On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that =E2=80=9C= orchestration=E2=80=9D is separate from what the classical =E2=80=9Cclient= =E2=80=9D in OAuth is doing =E2=80=94 but the term =E2=80=9Corchestrator=E2= =80=9D fits with the =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s be= en brought up here before, so I=E2=80=99m inclined to believe it can be a s= eparate role from the client.

I personally think that = =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient = of the grant=E2=80=9D but rather a =E2=80=9Cclient of the resource=E2=80=9D= .

I also think it=E2=80=99s problematic to lump in= user claims with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going t= o muddle everything.=C2=A0

=C2=A0=E2=80=94 Justin<= br>

On Aug 11, 2020, at 3:25 PM, Dic= k Hardt <dick.= hardt@gmail.com> wrote:

I echo Mike's comments on preservin= g names when possible. The shift from "consumer" in OAuth 1 to &q= uot;client" in OAuth 2 was confusing to many.

=
I also echo Tom's comments about separating Entities from Roles.

Orchestration[1] in my opinion is not what the &quo= t;client" is doing.

Below is a stab at separa= ting the entities and the roles

/Dick
Tl;dr:=C2=A0
- Client=C2=A0-> Grant Client=
- added Relying Party, Claims Issuer, and Grant Server Operator = as entities

Roles - parties to the pro= tocol
Grant Client (GC), Grant Server (GS), Resource Server (RS)<= /div>

Entities - parties to a Tr= ust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant S= erver Operator (GSO), Resource=C2=A0Owner (RO)
<= br>
Grant -=C2=A0may contain claims and/or access to resou= rces

#Protocol Roles

Grant Client (GC)
- used by User
- operated /= provided by RP
- requests Grants from the GS
- access = resources at an RS
- consumes Claims

= Grant Server (GS)
- operated by GSO
- may interact = with the User=C2=A0
- may interact with the RO
- accept= s grant requests from GCs
- issues grants to GCs
- may= issue claims

Resource Server (RS)
- manages access to resources for the RO
- provides access to r= esources for the GC
- accepts access granted by the GS
=
#Legal Entities

User<= /div>
- uses Grant Client
- may interact with the Grant Serve= r
- may also be a RO
- trusts RP, Issuer, GSO

Relying Party (RP)
- provides Grant Client= to the User.
- may trust Issuers, GSOs, and ROs

<= /div>
Claims Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant= Server Operator (GSO)
- operates the GS
- trusted = by User, RP, and RO
- may also be an Issuer

=
Resource Owner (RO)
- owns resources at the RS<= /div>
- trusts GSO to control access to the resources
- may b= e same entity as the User
- may also be an Issuer
=


Orchestration (computin= g)

From Wikipedia, the free encyclopedia
Jump to navigationJump t= o search
In=C2=A0system administ= ration,=C2=A0orchestration=C2=A0is the automated=C2=A0configuration, coordination, and manage= ment of computer systems and=C2=A0software<= /a>.[1]
A=C2=A0number of= tools exist=C2=A0for automation of server configuration and management= , including=C2=A0Ansible,=C2=A0Puppet,=C2=A0Salt,=C2=A0<= a href=3D"https://en.wikipedia.org/wiki/Terraform_(software)" title=3D"Terr= aform (software)" style=3D"text-decoration-line:none;color:rgb(11,0,128);ba= ckground:none" target=3D"_blank">Terraform,[2]= =C2=A0and=C2=A0AWS CloudFormation.[3]

= Usage[e= dit]

Orchestration is often discussed in = the context of=C2=A0ser= vice-oriented architecture,=C2=A0virtualization,=C2=A0provisioning,=C2=A0converged infrastructure=C2=A0and dy= namic=C2=A0datacenter=C2=A0topics. Orchestration in this = sense is about aligning the business request with the applications, data, a= nd infrastructure.[4]
In the context of=C2=A0cloud computing, = the main difference between=C2=A0workflow a= utomation=C2=A0and orchestration is that workflows are processed and co= mpleted as processes within a single domain for automation purposes, wherea= s orchestration includes a workflow and provides a directed action towards = larger goals and objectives.[1]
In this context, and with the overall aim to ach= ieve specific goals and objectives (described through=C2=A0quality of service=C2=A0parameters), for example, meet ap= plication performance goals using minimized cost[5]=C2=A0and maximize application performance w= ithin budget constraints.[= 6]





<= br>

On Tue, A= ug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:
<= /div>

One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

=C2=A0

Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

= From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match= any use case i have.

Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would = be in support of alternative terminology.

We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive= .=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

=C2=A0

I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

The term client in OAuth came from the computer= science definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

=C2=A0

The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

Ju= stin and Dick,

=C2=A0

[W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

=C2=A0

So= let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

Re= source Owner (RO): entity capable of granting access to a protected resourc= e

I = propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

D= enis

=C2=A0

I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

=C2=A0

For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

=C2=A0

/Dick

=E1=90=A7

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

=C2=A0

I think that is fundamentally part of the quest= ion:

We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warren Parad<= u>

Founder, CTO=

Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

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

=C2=A0

=C2=A0

Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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




--000000000000fd2d5b05acb0e3ba-- From nobody Wed Aug 12 09:52:29 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 ED5003A1423 for ; Wed, 12 Aug 2020 09:52:26 -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 WbvlcxTUJ5ce for ; Wed, 12 Aug 2020 09:52:24 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 8F3133A1422 for ; Wed, 12 Aug 2020 09:52:23 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id p20so2712987wrf.0 for ; Wed, 12 Aug 2020 09:52:23 -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=6EP/b/Ms2fHb4P2ie0tJarpgsmN4dJbKcttIJoQlFpU=; b=Vsm7kpoKE4lOC8HXKQx4769bQN1Hpjjy58IslbvIa2yhyCZQKp5rmssM84kUcYtuqC hJ4ebcHNs0RVkPcEiVF1k/Whwox9pnnlx1ErF987AzjJeIaDjFohXbvedeviJT26X7wb weUjxl4pCF+r0mfGnIN1myO2FGmK7dxdCs6IE= 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=6EP/b/Ms2fHb4P2ie0tJarpgsmN4dJbKcttIJoQlFpU=; b=rBYK5fri5P49bUl4ApbQ1nwyXkHQjsWptUq1jMcsYRo5UKQnCK5d20mAYbdMqTIRYP xE8o8VgaO1Rl40X2QhyCni9mdoL+Pynsn/xs0pjcl8lYgdx4NPPpY1bitn040O7wdBdv ydkvoLVwovTgoYCyk1+OyRd8ZJtlM2Vl8epJVjg7tauhkxdww9gr0hr1oYai+H+O6YeL KZ6eZodU0wdBLCOvWh2Bv1zIv0X3ObFXW48XTsPEAiwfBeJ9/kMGo4B8ZKNcDBaJq4Mt T2RK6Xfsupmxns+TUWAWDTUuRvD+uCd2y9Ltna7jmozoKmvBk2As5DazUrSTwD9bdHwu 53nw== X-Gm-Message-State: AOAM532m29BDeZRcUmWWrW+5fWyNCHSgo4LFanro3WHV6h3/zfRydrYt Ct/5LDWdiX4BuaYePaSiBFzzMiWdUxkYT4fW5CW3Lw== X-Google-Smtp-Source: ABdhPJxx3W60ZofDYJjQ1hjEERnfenVIZP5mi+qGSqmthi/WtteopFedu+G6qnBvMw1osSdaoO4whxUr0s2K/JcgefE= X-Received: by 2002:adf:cc88:: with SMTP id p8mr159085wrj.70.1597251141906; Wed, 12 Aug 2020 09:52:21 -0700 (PDT) MIME-Version: 1.0 References: <7d64ec8b-2fb6-a0c7-c649-f4f4c9cc00a1@free.fr> <319DAB20-198D-48B7-B0B8-72881D234633@mit.edu> In-Reply-To: <319DAB20-198D-48B7-B0B8-72881D234633@mit.edu> From: Francis Pouatcha Date: Wed, 12 Aug 2020 12:52:10 -0400 Message-ID: To: Justin Richer Cc: Denis , Fabien Imbault , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000ee494f05acb102cb" Archived-At: Subject: Re: [GNAP] [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD) 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: Wed, 12 Aug 2020 16:52:27 -0000 --000000000000ee494f05acb102cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for this approach. On Wed, Aug 12, 2020 at 12:07 PM Justin Richer wrote: > Hi Denis, > > I think this is a fascinating approach that can allow for > privacy-preservation in the way that you=E2=80=99re after. Here=E2=80=99s= how I would see > it fitting into GNAP: > > When the client makes the request, it includes the > concealed_target_identifer in the resources request, probably in lieu of > any kind of =E2=80=9Clocation=E2=80=9D field. The semantics of this field= could be defined > in GNAP core or in a short extension describing the reusable field in the > =E2=80=9Cresources=E2=80=9D request: > > resources: [ > =E2=80=9Caction": [=E2=80=9Cread=E2=80=9D], > =E2=80=9Cconcealed_target_identifier=E2=80=9D: =E2=80=9C876tghjkjasdf7= 234f=E2=80=9D > ] > concealed_target_identifier is either provided by server in step (2) or computed by client using a property unique to the RS (location-url) and a nonce (Target-Identifier-Random-Number). > At that point, it=E2=80=99s up to the AS to bind that identifier to the r= esulting > access token and make that information available to the RS. That could > happen by packing it into a JWT, which is likely the format you=E2=80=99d= want for > this kind of thing because an introspection call from the RS would identi= fy > the RS to the AS. > > The missing piece is a way for the client to present the random number to > the RS alongside the access token. I think this would make sense as a > separate HTTP header defined in that extension. So the client would get > back its token and send this to the RS: > > Authorization: GNAP eyj0=E2=80=A6 > Target-Identifier-Random-Number: ABE54298411... > Nonce is added to the request header to allow RS to validate the target of the authz token. /Francis > > > The RS would look at the token, find the hashed value within, and use the > value in the secondary header to recalculate and verify the hash on the > request. All of this can be done without the RS calling the AS and withou= t > the client divulging the RS=E2=80=99s location or identity to the AS. > > =E2=80=94 Justin > > > On Aug 12, 2020, at 10:34 AM, Denis wrote: > > Hi Fabien, > > Thanks Denis. > > A few questions to clarify: > - "the field included into the access token will look like a random numbe= r > to the RS." - you mean AS? > > Correct. This was a typo. > > - "It should have two parts : a signed part and an unsigned part." - > Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (wit= h > short expiry) between the temporary_id and the url, on the RS side? > > Sorry, I am not aware of this scheme. > > Then the algorithm would be : > 1. Client contacts the RS, which sends a resource description > (temporary_id) > > No. It is not a temporary_id. > > 2. The flow continues and a token is generated, using the temporary_id. > > No. Knowing the true identifier of the RS, the Client picks a > random_number and computes a concealed_target_identifier =3D hash > (random_number, RS_identifier). > > While requesting an access token, the Client asks the AS to include the > concealed_target_identifier into the access token. > > While sending the access token, the Client adds the random_number into th= e > unsigned part of the access token. > > While receiving the access token, the RS uses it own RS_identifier and > retrieves the random_number placed into the unsigned part of the access > token. > It then computes a hash of (random_number, RS_identifier). If the result > matches with the concealed_target_identifier placed into the signed part = of > the access token, then the access token is well targeted, otherwise it is > ignored. > > 3. Client makes the call to the RS, using the token. The RS verifies the > signature + it also verifies that the mapping is the one expected. > > BTW, it makes the RS decide the maximum token expiry. > > Token expiration is unrelated. > > The issue is that it requires more work on the RS side, compared to a > stateless JWT. > > Adding two computations using a one way hash function is not a big deal. > > Is that correct? > > No. The mechanism is fairly different. It has already been explained once > on the OAuth mailing list. > > Denis > > > Fabien > > > On Wed, Aug 12, 2020 at 3:24 PM Denis wrote: > >> With so many messages in the last 24 hours, I can't respond to all of >> them at once. >> I picked the last one first. >> >> Inline too :-) >> >> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha wrote: >> >>> Hello Fabian, inline >>> >>> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault >>> wrote: >>> >>>> Hi Francis, >>>> >>>> My comments are embedded into your email with FI. >>>> >>>> You're saying in a follow-up message: >>>> "- If you want privacy, *don't* expose RS identity to AS. >>>> - If you want transparency, expose RS identity to AS. >>>> You can't have both...." >>>> While that may seem a reasonable dichotomy at first sight, I believe >>>> the reality is actually more nuanced and depends on how we end up desi= gning >>>> the system. >>>> >>> [Denis] This is in fact more nuanced. It is possible to prevent the AS >> to know who the RS is by hiding the true identifier of the RS to the AS. >> >> This means that for security reasons the access token is still targeted >> but that the field included into the access token will look like a rando= m >> number to the RS. >> That random number will change for every access token. >> >> In order for the RS to make sure that the access token is indeed intende= d >> for itself, it will need to combine the field included into the access >> token >> with an unsigned field external to the access token. >> >> This would have a major consequence for the structure of a GNAP access >> token that will be rather different from an OAuth 2.0 access token. >> It should have two parts : a signed part and an unsigned part. >> >> >>>> Cheers, >>>> Fabien >>>> >>>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha >>>> wrote: >>>> >>>>> Hello Fabian, >>>>> >>>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi Francis, >>>>>> >>>>>> I think Denis points to the fact that, in the current situation, the >>>>>> AS receives the resource request from the Client and therefore knows= what >>>>>> tokens are asked. >>>>>> >>>>> The token request must not mention any reference of the RS. >>>>> >>>> >>>> FI : yes we can do that, but as Tom commented, it's not a general rule= . >>>> And for instance in XYZ you do describe the URL of the resource. See a= lso >>>> the use case on directed tokens, which is an interesting topic which m= akes >>>> sense in many scenarios. >>>> >>> Yes. But disclosing the protected resource discloses the RS. >>> >> >> FI : yes of course. Which is why RS hiding may be a solution. >> >>> >>> But as soon as you include that possibility, it's fair to think that >>>> this capability could be used for surveillance purposes in some cases, >>>> unless you found a privacy by design scheme that applies by default. >>>> >>> Yes. THen default shall be using URI of resource description and not UR= L >>> to indicate resource location. >>> >> >> FI : yes >> >>> >>> Again this doesn't mean that transparency requirements aren't important >>>> too, but I think there are other ways it can be achieved (for instance= , an >>>> inspiration is the certificate transparency project). Could be an exte= nsion >>>> to the protocol I believe. >>>> >>> The certificate transparency deals with something else. Does not fit in >>> this context at all. >>> >>> >> FI : It does, and has already been implemented by some projects in >> relationship with OAuth2, as an additional component. >> >>> >>>> >>>>> >>>>>> Then it also implements the consent interface (and possibly the logi= n >>>>>> too) and so it also knows who validates and what is accepted or not. >>>>>> >>>>> Decoupling this does not change the privacy context, as the AS issues >>>>> the Token. AS needs to add a reference to the RC in the token. SO AS = can >>>>> correlate on StudentId anyway. >>>>> >>>> >>>> FI : I disagree. It does change the privacy context, if as Denis >>>> suggested, the consent is made outside of the AS and if you don't send= to >>>> the AS the information on the RS when it needs to issue the token. >>>> Correlation on StudentId is limited as long as it's a local identifier= , >>>> i.e. not a public DID. >>>> >>> How local can the StudentId be? It is known to both universities and to >>> the AS. Without a public reference, you can not link information betwee= n >>> unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Th= en >>> you do not need central AS anymore. >>> >> >> FI : see keri or peer DID for instance, as examples of local ID. >> Again SSI/DID/VC doesn't mean you don't need AS, those technologies can >> be complementary. >> >> >>> >>>> As a concrete example: a user may want to use an application to access >>>> rs_domain/directory1 and rs_domain/directory2 in read and write, which= are >>>> managed by a RO. >>>> What I suggested is that the Client may (optionally) carry out its >>>> consent through a decoupled IS server (separated from the AS), that >>>> displays the UI based on the RS requirements =3D> the IS knows what >>>> information is used, but the IS may be chosen by the IS independently = from >>>> the AS or even run by the Client itself. >>>> >>> What do you need an AS for? Then it can sign the claim to present to RS= . >>> >> >> FI : to be sure, what is "it"? >> >> >>> >>> >>>> In this case, suppose the RO only provided consent for >>>> rs_domain/directory1 for read. >>>> We now need to get back to the AS to mint the access token. >>>> >>> If AS mint access token, AS will be able to correlate. Unless start >>> applying intransparent complex reference mapping techniques, wich might >>> even open room for new attack vectors. >>> >> >> FI : not necessarily with respect to correlation, see above. >> As for mapping techniques, this is the very reason of my question to >> Denis. >> >>> >>> >>>> If we want the AS to not know about the RS, we either : >>>> - don't supply the rs_domain at all -> the JWT says that directory1 in >>>> read access is authorized. The downside is that we actually cannot con= trol >>>> to which URL the authorization applies. In that case I agree with your >>>> either or statement. >>>> >>> Yes >>> >>>> - or find a way to hide it (not sure if that's practical, hence my >>>> questions on RS hiding). This would have the benefit of still allowing >>>> directed tokens -> the JWT says that rs_petname/directory1 in read acc= ess >>>> is authorized. >>>> >>> More complexity. >>> >> >> FI : yes >> >> [Denis] As indicated at the top of this email, it is possible to always >> hide the identifier of the RS while still targetting every access token. >> >> BTW, I have expanded the notion of targetting by allowing to place into = a >> target field of an access token either or both a RS identifier and >> a Service Name (SN) identifier to which the RS belongs. >> >> Two targetting fields should hence be possible: a RS identifier and a SN >> identifier. >> >> This is also a difference with an OAuth 2.0 access token. >> >> Either way, the AS has not been provided any information as to where thi= s >>>> token will effectively be used. >>>> >>> >>>>> >>>>>> I don't think the abstract flow deals with those privacy concerns. >>>>>> >>>>> To solve the privacy problem addressed in this thread, we need to go >>>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to is= sue a >>>>> VC (Verifiable Credential) to the Student (in his role of RC). The St= udent >>>>> will then present this claim to UNIV-1 during his registration. In th= is >>>>> case we need no Grant negotiation and no AS. >>>>> >>>> [Denis] This is a complete redesign of my example and hence this >> redesign has no relationship with my example. >> >> >>>> FI : That may be useful but it's not enough. What you describe only >>>> works because you take a very specific use case, aka registration. Thi= s >>>> fits well into DID/VC without requiring authorization per say. However >>>> grant negotiation is still required for more general settings of >>>> authorization. >>>> >>> Please drop the next use case in the repo, so we can dive deeper into i= t >>> and see how to provide both central grant negotiation and privacy. >>> >> >> FI : will do. >> >>> >>> I've added a DID example to my implementation, will publish it soon. >>>> >>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>>> >>>>>> Then I agree with you on the audience field of the token, if left >>>>>> empty it simplifies part of the problem, although it removes a big p= art of >>>>>> the control you may want from directed tokens. That's why I'm willin= g to >>>>>> better develop the RS hiding idea. >>>>>> >>>>>> Fabien >>>>>> >>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha >>>>> 40adorsys.de@dmarc.ietf.org> a =C3=A9crit : >>>>>> >>>>>>> Hello Denis, >>>>>>> >>>>>>> what you describe in the use case seems to be the default behavior >>>>>>> of the protocol. Let me map it with this abstract protocol flow: >>>>>>> >>>>>> [Denis] The redesign below has no relationship with my use case. >> >> A key element of my design is the User, i.e. a physical person which >> initiates the exchanges. In the example below the User has disappeared. >> >> A User is not a role, but an entity. >> >> BTW, I can't understand the role of an "Orchestrator" (which is left >> undefined). >> >> >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> | Requestor | | Orchestrator | | RS | | GS | | >>>>>>> Resource Controller | >>>>>>> | is UNIV-1 | | is UNIV-1 | | is UNIV-0 | | or | | >>>>>>> is | >>>>>>> | Staff | | Registr. App | | Server | | AS | | >>>>>>> Student | >>>>>>> +-----------+ +--------------+ +-----------+ +----+ >>>>>>> +---------------------+ >>>>>>> |(1) RegisterStudent | | | >>>>>>> | >>>>>>> |---------------------->| | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecordIntent(RecordType,StudentId, >>>>>>> | | >>>>>>> OrchestratorId):AuthRequest[RecordType,StudentId] >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(3) >>>>>>> AuthZRequest(RecordType,StudentId,OrchestratorId) >>>>>>> | |--------------------------->| >>>>>>> | >>>>>>> | | | |(4) >>>>>>> ConsentRequest(RecordType, >>>>>>> | | | | >>>>>>> OrchestratorId):Consent >>>>>>> | | | >>>>>>> |<-------------->| >>>>>>> | >>>>>>> |(5) AuthZ[RecordType,StudentId,OrchestratorId] >>>>>>> | |<---------------------------| >>>>>>> | >>>>>>> | | | | >>>>>>> | >>>>>>> | |(2) >>>>>>> RequestRecord(RecordType,StudentId,OrchestratorId) >>>>>>> | | :RecordOf[StudentId] | >>>>>>> | >>>>>>> | |<-------------->| | >>>>>>> | >>>>>>> |(7) Registered | | | >>>>>>> | >>>>>>> |<----------------------| | | >>>>>>> | >>>>>>> + + + + >>>>>>> + >>>>>>> >>>>>>> we assume the authz request sent by "Client" to "AS" describes the >>>>>>> protected resource without referring to the authz server. An AS can= issue >>>>>>> the authz to release the graduation record of a student >>>>>>> ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any refer= ence to >>>>>>> the target university. >>>>>>> >>>>>>> What matters for this authz object is: >>>>>>> - StudentId: a reference to the student as known to the resource >>>>>>> server. >>>>>>> - RecordType: a reference to a resource of type graduation record a= s >>>>>>> understandable by the resource server. >>>>>>> - OrchestratorId: reference to the Orchestrator. Can be used to bin= d >>>>>>> authz to Orchestrator. >>>>>>> >>>>>>> But: >>>>>>> - RS must trust AS issued token. >>>>>>> - StudentId must be known to RS, AS and Orchestrator. >>>>>>> >>>>>>> Therefore, the AS does not need to know the RS. Keep the audience >>>>>>> field empty. >>>>>>> >>>>>>> Same principle applies for the second use case. >>>>>>> >>>>>>> What privacy problem do you see here? >>>>>>> >>>>>> [Denis] The User, a physical person which initiates the exchanges ha= s >> disappeared. >> No more user, no more privacy issues ? :-) >> >> Denis >> >> >>>>>>> Best regards. >>>>>>> /Francis >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 5:08 AM Denis wrote: >>>>>>> >>>>>>>> I tried my best twice to download three use cases in the Use cases >>>>>>>> directory, but I failed. >>>>>>>> >>>>>>>> Rather than failing a third time, here is the direct link of the >>>>>>>> second try: >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-u= se-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) >>>>>>>> >>>>>>>> Denis >>>>>>>> >>>>>>>> >>>>>>>> -- >>> 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 >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000ee494f05acb102cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for this approach.
On W= ed, Aug 12, 2020 at 12:07 PM Justin Richer <jricher@mit.edu> wrote:
Hi Denis,
I think this is a fascinating approach that can allow for= privacy-preservation in the way that you=E2=80=99re after. Here=E2=80=99s = how I would see it fitting into GNAP:

When the cli= ent makes the request, it includes the concealed_target_identifer in the re= sources request, probably in lieu of any kind of =E2=80=9Clocation=E2=80=9D= field. The semantics of this field could be defined in GNAP core or in a s= hort extension describing the reusable field in the =E2=80=9Cresources=E2= =80=9D request:

resources: [
=C2=A0 =C2= =A0=E2=80=9Caction": [=E2=80=9Cread=E2=80=9D],
=C2=A0 =C2=A0= =E2=80=9Cconcealed_target_identifier=E2=80=9D: =E2=80=9C876tghjkjasdf7234f= =E2=80=9D
]
concealed_target_identif= ier is either provided by server in step (2) or computed by client using a = property unique to the RS (location-url) and a nonce (Target-Identifier-Ran= dom-Number).=C2=A0


At that point, it=E2=80=99s up to the AS to bind that identifier to the re= sulting access token and make that information available to the RS. That co= uld happen by packing it into a JWT, which is likely the format you=E2=80= =99d want for this kind of thing because an introspection call from the RS = would identify the RS to the AS.=C2=A0

The missing= piece is a way for the client to present the random number to the RS along= side the access token. I think this would make sense as a separate HTTP hea= der defined in that extension. So the client would get back its token and s= end this to the RS:

Authorization: GNAP eyj0=E2=80= =A6
Target-Identifier-Random-Number: ABE54298411...
Nonce is added to the request header to allow RS to validat= e the target of the authz token.=C2=A0

/Francis


The RS would look at= the token, find the hashed value within, and use the value in the secondar= y header to recalculate and verify the hash on the request. All of this can= be done without the RS calling the AS and without the client divulging the= RS=E2=80=99s location or identity to the AS.

=C2= =A0=E2=80=94 Justin


O= n Aug 12, 2020, at 10:34 AM, Denis <denis.ietf@free.fr> wrote:

=20
Hi=C2=A0 Fabien,
=20
Thanks Denis.

A few questions to clarify:=C2=A0
- "the field included into the access token will look like a random number to the RS." - you mean AS?

Correct. This was a typo.

- "It should have two parts : a signed part and an unsigned part." - Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with short expiry) between the temporary_id and the url, on the RS side?

Sorry, I am not aware of this scheme.

Then the algorithm would be :
1. Client contacts the RS, which sends a resource description (temporary_id)

No. It is not a temporary_id.=C2=A0

2. The flow continues and a token is generated, using the temporary_id.

No. Knowing the true identifier of the RS, the Client p= icks a random_number and computes a concealed_target_identifier =3D=C2=A0 ha= sh (random_number, RS_identifier).

While requesting an access toke= n, the Client asks the AS to include the concealed_target_identifier into the access token.

While sending the access token, the Client adds the random_numbe= r into the unsigned part of the access token.

While receiving the access token, the RS uses it own RS_identifier and retrieves the random_number placed into the unsigned part of the access token.
It then computes a hash of (random_number, RS_identifier). If the result matches with the concealed_target_identifier placed into the signed part of
the access token, then the access token is well targeted, otherwise it is ignored.

3. Client makes the call to the RS, using the token. The RS verifies the signature=C2=A0+ it also verifies that the mapping is the one expected.=C2=A0=C2=A0

BTW, it makes the RS decide the maximum token expiry.

Token expiration is unrelated.

The issue is that it requires more work on the RS side, compared to a stateless JWT.=C2=A0

Adding two computations using a one way hash function i= s not a big deal.

=C2=A0Is that correct?

No. The mechanism is fairly different. It has already b= een explained once on the OAuth mailing list.

Denis


Fabien


On Wed, Aug 12, 2020 at 3:2= 4 PM Denis <denis.ietf@free.fr> wrote:
With so many messages in the last 24 hours, I can't respond to all of them at once.
I picked the last one first.

Inline too :-)

On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <fabien.imbault@gmail= .com> wrote:
Hi Francis,=C2=A0

My comments are embedded into your email with FI.

You're saying in a follow-up message:=C2=A0
"- If you want privacy,=C2=A0d= on't=C2=A0expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem=C2=A0a reasonable=C2=A0dichotomy=C2=A0at first s= ight, I believe the reality is actually more nuanced and depends on how we end up designing the system.

[Denis] This is in fa= ct more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.

This means t= hat for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
That random number will change for every access token.

In order for the RS t= o make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token
with an unsigned field external to the access token.

This would have a maj= or consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.


Cheers,
Fabien

On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
Hi Francis,

I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case=C2=A0on directed tokens= , which is an interesting topic which makes sense in many scenarios.=C2=A0=C2= =A0
Yes. But disclosing the protected resource discloses the RS.=C2=A0

FI : yes of course. Which is why RS hiding may be a solution.=C2=A0

But as soon as you include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default.=C2=A0
Yes. THen default shall be using URI of resource description and not URL to indicate resource location.=C2=A0

FI : yes=C2=A0

Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe.=C2=A0
The certificate transparency deals with something else. Does not fit in this context at all.
=C2=A0
FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component.=C2=A0

=C2=A0
Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the=C2=A0RC in the token. SO AS can correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to th= e AS the information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID.=C2=A0
How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.

FI : see keri or peer DID for instance, as examples of local ID.=C2=A0
Again SSI/DID/VC doesn't mean you don't ne= ed AS, those technologies can be complementary.=C2=A0
=C2=A0

As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO.=C2=A0
What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements =3D> the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself.=C2=A0
What do you need an AS for? Then it can sign the claim to present to RS.

FI : to be sure, what is "it"?=C2=A0
=C2=A0
=C2=A0
In this case, suppose the RO only provided consent for rs_domain/directory1 for read.=C2=A0
We now need to get back to the AS to mint the access token.=C2=A0
If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis.=C2=A0


If we want the AS to not know about the RS, we either :=C2=A0
- don't supply the rs_domain at al= l -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization=C2=A0applies. In that case = I agree with your either or statement.=C2= =A0=C2=A0
Yes=C2=A0
- or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
More complexity.=C2=A0

FI : yes

[Denis] As indicated = at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.

BTW, I= have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN identifier.

This is also a difference with an OAuth 2.0 access token.

Either way, the AS has not been provided any information as to where this token will effectively be used.=C2= =A0=C2=A0


I don't thi= nk the abstract flow deals with those privacy concerns.=C2=A0
To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and=C2=A0= no AS.

[Denis] This is a com= plete redesign of my example and hence this redesign has no relationship with my example.


FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation=C2=A0is still required for mo= re general settings of authorization.=C2=A0= =C2=A0
Please drop the next use case in the=C2=A0repo, so we can dive deeper into it an= d see how to provide both central grant negotiation=C2=A0and privacy.

FI : will do.=C2=A0

I've added a DID example to my implementation, will publish it soon.=C2= =A0

=C2=A0
Best regards.
/Francis
=C2=A0

Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea.=C2= =A0

Fabien=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@d= marc.ietf.org> a =C3=A9crit=C2=A0:
Hello=C2=A0Den= is,

what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:

[Denis] The redesign = below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.

A User = is not a role, but an entity.

BTW, I can&#= 39;t understand the role of an "Orchestrator" (which is left undefined).=


+-----------+=C2=A0 =C2=A0 =C2=A0 +--------= ------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+----------------= -----+
| Requestor |=C2=A0 =C2= =A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
| is UNIV-1 |=C2=A0 =C2= =A0 =C2=A0 |=C2=A0 is UNIV-1=C2=A0 =C2=A0|= =C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0o= r |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0Staff=C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |= =C2=A0 |=C2=A0AS |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-----------+=C2=A0 =C2= =A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2=A0+----+ =C2=A0+----------------= -----+
=C2=A0 |(1) RegisterStudent=C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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|(2= ) RequestRecordIntent(RecordType,StudentId,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0OrchestratorId):A= uthRequest[RecordType,StudentId]
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------------= -->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 =C2=A0 =C2=A0 =C2=A0|(3= ) AuthZRequest(RecordType,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|----------------= ----------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =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) ConsentRequest(RecordTy= pe,
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):C= onsent
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<------------= -->|
=C2=A0 |=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=A0AuthZ[R= ecordType,StudentId,OrchestratorId]
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------------= ---------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= (2) RequestRecord(RecordT= ype,StudentId,OrchestratorId)
=C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0:RecordOf[Stude= ntId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<------------= -->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<= br> =C2=A0 |(7) Registered= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |<------------------= ----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +

we assume the authz request sent by "Client" to &qu= ot;AS" describes the protected resource without referring=C2=A0to the authz server. An AS can issue the authz to release the graduation record=C2=A0 o= f a student ((5)=C2=A0AuthZ[RecordTyp= e,StudentId,OrchestratorId]), without any reference to the target university.=C2=A0<= /div>

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as understandable=C2=A0 by t= he resource server.
-=C2=A0OrchestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.

But:
- RS must trust AS issued token.
-=C2=A0StudentId must be known to RS, AS and=C2=A0Orchestrator.=

Therefore, the AS does not need to know the RS. Keep the audience field empty.

Same principle applies for the second use case.

What privacy problem do you see here?

[Denis] The User, a p= hysical person which initiates the exchanges has disappeared.
No more user, no more privacy issues ? :-)

<= font color=3D"#0000ff">Denis


Best regards.
/Francis

On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@fre= e.fr> wrote:

I tried my best twice to download three use cases in the Use cases directory, but I failed.

Rather th= an failing a third time, here is the direct link of the second try:

https://github.com/ietf-wg-g= nap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along= -%22Privacy-by-Design%22-(PbD)

Denis


--
Francis Pouatcha
Co-Founder and Technical Lead


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


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



--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
<= /div> --000000000000ee494f05acb102cb-- From nobody Wed Aug 12 09:55:15 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 743BB3A13C8 for ; Wed, 12 Aug 2020 09:55:13 -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 RIOPvx9PKLLn for ; Wed, 12 Aug 2020 09:55:11 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 2A36A3A12ED for ; Wed, 12 Aug 2020 09:55:11 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id h8so1523671lfp.9 for ; Wed, 12 Aug 2020 09:55:11 -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=4tUAGpIguTgh0QIr0F12XHpuGV/QZrcbZvNZRx6BgvQ=; b=Mpku7UOAI4NB+u0H/VcOglDvcfIm0gyijSt0pYGM5ZX+E6zliISq6HkERhgDelk56E PQHSqRcULQRHxNiQieP1BdCvibQ5iuDGjZdgSmGQtiRJdq3UQiu2oM5zLe4ZHjfGnltE j/AN6vhSzIbNpi3L32kbRbY/FsvSEo6Ao1eg0hAlsuck6mBQb0s0DmSVR7KBXXsBmt+J 3OZtdrWbpoQ48gcx3Eicm1aPWzKvq9ZmC1W41VEjBLCGNsNbrKUCUXPmV7t3U7JmB5kT 40ELA4zqqNJ5z56J5dV18X/5t80Mvy0FH8ncziW1Tq+pu767ejzGsh+5LRKFCciHnka0 Anqg== 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=4tUAGpIguTgh0QIr0F12XHpuGV/QZrcbZvNZRx6BgvQ=; b=fgU8tWiMOFaN/35TYp9ssHisXjdrihL0ifwYR4gDznDMVt/OJ/Hwch3efCmKmfu9xI A7/pq58aP9fZEcU8us0k4H8i1yqaVZ5HuYLvnnaYo1xcPIObjjK2ZYPYZnPCzpw61hlt ukxTFj23pk8FTqJGzkvZtlwq7CiqdVW4FwCkxRWec0LZPPalPb8XmFIlpVOxcm+iQt/e s1qFUIBfa4Be1QWA2mCtlFhFoj/MoK18YVdSPiv3f3XSUaPXSOiIDkmAJZaS9Jr6t9XA dolSbgvE8WD83gQ4pSgyuBuEBq8doqxOublB8vagEKjeAjpIaL4TyuK+Ph6Gj/ni6OiT vjyQ== X-Gm-Message-State: AOAM533PxFUxUfiVTWcO/AFIUreBazKuL0QpxBUZQFNTvmfeMYHbEiJt 0bqpOCbV9TdaAPSqZqPg237oK3exQRB9KdQk8SY= X-Google-Smtp-Source: ABdhPJyTa+p7IgmpDifWqcrp+/pjHfO5izp74wFSeFG1chu9mzKDR1S3tSo/36Fcv0CgzTKVKe0ZwfYJvUIuqTtDBWo= X-Received: by 2002:ac2:5f48:: with SMTP id 8mr151358lfz.157.1597251309210; Wed, 12 Aug 2020 09:55:09 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> In-Reply-To: <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> From: Dick Hardt Date: Wed, 12 Aug 2020 09:54:32 -0700 Message-ID: To: Denis Cc: Francis Pouatcha , Justin Richer , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e70fd205acb10c97" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 16:55:14 -0000 --000000000000e70fd205acb10c97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable comments inline ... On Wed, Aug 12, 2020 at 7:14 AM Denis wrote: > Hi Dick, > > Hi Francis, responses inline ... > > On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha wrote: > >> Hello Dick, >> >> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt wrote: >> >>> Hi Francis >>> >>> The user is an entity, not a role in the protocol in how I am defining >>> roles, so steps (1) and (7) are confusing to me on what is happening. >>> >> "Requestor" is the role (*was* User). So the UML participant refers to >> the role "Requestor" >> > > I still don't understand what is happening in (1) and (7) > > Would you provide more explanation? > > >> >> >>> I also think that (2) could be an extension to GNAP, rather than part o= f >>> the core protocol. >>> >> If you make it an extension, you hide. It shall rather be an optional, >> integral part of the protocol. >> > > Most deployments today accomplish (2) by the developer reading RS > documentation. I'm in favor of showing that step in an abstract diagram. > > [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag > f=C3=B6rst=C3=A5r inte svenska. Jeg forst=C3=A5r ikke norsk. > > One of the goals is for any Client to access any RS without the need to > read any documentation. > That is impractical. Most RSes today have resource specific APIs. The Client is either reading a standard API doc, or the resource specific API doc. > But it is not clear to me what the requirements for (2), and they may var= y > radically across use cases, so putting it in the core document seems to b= e > getting ahead of ourselves. > > [Denis] I can only reinsist on earlier explanations given about the > Client-server use cases built along "Privacy by Design" since they are > fundamental. > I agree with the principle of "Privacy by Design". There are LOTS of details in how to do what you outline below, and I expect they will be radically different across use cases, which is why I don't think it fits into the core document, but I do agree with calling it out in the abstract. When I publish an updated draft, let me know what you think then. > > Taking into consideration both the "data minimization" principle and the > "user participation" principle when a user first authenticates to a RS > leads to the following: > > 1) When accessing a RS for the first time, the user should be informed of > the authentication means proposed by the RS. The user should be able to u= se > a dialog box > where some choices are presented by the RS. The user should be able to > locally make his own choices and to indicate his consent to its Client. > > 2) When a user chooses to perform one operation on a RS, the RS should > limit the data to be collected from the user to only what is strictly > necessary > to perform that operation. That data consists of specific types of > attributes that need to be guaranteed by one or more ASs. The user should > be able > to use a dialog box where some ASs choices are proposed by the RS. The > user should be able to locally make his own choices and to indicate > his consent to its Client. > > It is important to notice that the choices that will be proposed to a use= r > may depend upon previous personal information voluntarily released by tha= t > user. > This means that the choices proposed by the RS may be tailored for the > user. Furthermore, the proposed choices may only be disclosed to already > authenticated users. > > Denis > > > >> In some open banking designs, >> - the "Orchestrator/Negotiator/Client" will not know the AS to talk to >> unless the call (2). >> > > Have you put these use cases in the wiki? > > >> - the request (2) might result in an exemption, meaning no need for >> further authorization, allowing to skip (3, 4, 5) and even (6). >> > > Agreed. > >> =E1=90=A7 > > > =E1=90=A7 --000000000000e70fd205acb10c97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
comments inline ...=C2=A0

On Wed, Aug 12, = 2020 at 7:14 AM Denis <denis.ietf@= free.fr> wrote:
=20 =20 =20
Hi Dick,

=20
Hi Francis, responses inline ...=C2=A0

On Tue, Aug 11, 2020 at 3:3= 7 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). S= o the UML participant refers=C2=A0to the role "Requestor&q= uot;

I still don't understand what is happening in (1) and (7= )

Woul= d you provide more explanation?
=C2=A0
=C2=A0


I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol.

Most deployments today accomplish (2) by the developer reading RS documentation. I'm in favor of showing that step in an abstract diagram.

[Denis] Really by reading RS documentation ? Non capi= sco l'italiano. Jag f=C3=B6rst=C3=A5r inte svenska. Jeg forst=C3=A5r ikke norsk.

One of the goals is for any Client to access any RS without the need to read any documentation.


Tha= t is impractical. Most RSes today have resource specific APIs. The Client i= s either reading a standard API doc, or the resource specific API doc.
=C2=A0
But it is not clear to me what the requirements for (2), and they may vary radically across use cases, so putting it in the core document seems to be getting ahead of ourselves.

[Denis] I can only reinsist on earlier explanations given about the Client-server use cases built along "Privacy by Design" since they ar= e fundamental.

I agree wi= th the principle of "Privacy by Design". There are LOTS of detail= s in how to do what you outline below, and I expect they will be radically = different across use cases, which is why I don't think it fits into the= core document, but I do agree with calling it out in the abstract. When I = publish an updated draft, let me know what you think then.

=C2=A0


Taking into consideration both the "data minimization" principle and the "user participation" principle when= a user first authenticates to a RS leads to the following:

1) When accessing a RS for the first time, the user should be informed of the authentication means proposed by the RS. The user should be able to use a dialog box
where some choices are presented by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client.

2) When a user choo= ses to perform one operation on a RS, the RS should limit the data to be collected from the user to only what is strictly necessary
to perform that operation. That data consists of specific types of attributes that need to be guaranteed by one or more ASs. The user should be able
to use a dialog box where some ASs choices are proposed by the RS. The user should be able to locally make his own choices and to indicate
his consent to its Client.

It is important to notice that the choices that will be proposed to a user may depend upon previous personal information voluntarily released by that user.
This means that the choices propose= d by the RS may be tailored for the user. Furthermore, the proposed choices may only be disclosed to already authenticated users.

Denis

=C2=A0
In some open banking designs,=C2=A0
- the "Orchestrator/Negotiator/Client" will = not know the AS to talk to unless the call (2).

Have you put these use cases in the wiki?
=C2=A0
- the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

Agreed.
3D""==E1=90=A7


3D""= =E1=90=A7
--000000000000e70fd205acb10c97-- From nobody Wed Aug 12 09:55:46 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 92BDE3A12ED for ; Wed, 12 Aug 2020 09:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RopeAoZPfMqw for ; Wed, 12 Aug 2020 09:55:41 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369113A13C8 for ; Wed, 12 Aug 2020 09:55:40 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CGtasn012469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 12:55:37 -0400 From: Justin Richer Message-Id: <417CAA5C-3F64-4284-95C6-CA58E07AF7F0@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1AC4C4AE-D5CE-4956-BEEF-8186A06A3CEB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 12:55:36 -0400 In-Reply-To: Cc: Benjamin Kaduk , "txauth@ietf.org" To: Denis References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 16:55:45 -0000 --Apple-Mail=_1AC4C4AE-D5CE-4956-BEEF-8186A06A3CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis, This isn=E2=80=99t mandated, this is one optional flow for the cases = where the RS :wants: to talk to the AS.=20 =E2=80=94 Justin > On Aug 12, 2020, at 12:02 PM, Denis wrote: >=20 > Justin, >=20 > A soon as the RS needs to talk to the GS (step 2a) , it is a "Big = Brother by Design" architecture.=20 > Do you want to mandate it ? >=20 > Denis >=20 >> +1 to this. I think that the core protocol needs to be designed to = allow this kind of action, but I also think it is possible that the = details of this could end up in an extension to the main document. = I=E2=80=99ve put a flag in the ground for this in XYZ in sections 10.3 = and 10.4, which is adapted from UMA2=E2=80=99s distributed authorization = protocol: >>=20 >> = https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10= .3 = >>=20 >> The important detail here, in XYZ=E2=80=99s design, is that the RS = has a clear way to communicate to the client what will be needed to = fulfill the request, and the client/orchestrator/whatever has a clear = way to incorporate that into the main protocol. The details of (2) using = the XYZ pattern are: >>=20 >> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >> | Requestor | | Orchestrator | | | | GS | | Resource = Controller | >> | was | | was | | RS | | or | | was = | >> | User | | Client | | | | AS | | Resource = Owner | >> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >> |(1) ServiceRequest | | | | >> |---------------------->| | | | >> | |(2) ServiceIntent:AuthZChallenge | >> | |----------->| | | >> | | | | | >> | | |(2a) Register resource set >> | | |------>| | >> | | | | | >> | | |(2b) Return resource = reference handle >> | | |<------| | >> | | | | | >> | |(2c) Return AS URL and resource reference = handle >> | |<-----------| | | >> | | | | | >> | |(3) AuthZRequest(AuthZChallenge, include = resource handle) >> | |------------------->| | >>=20 >>=20 >> Note that the client can ALSO request additional resources on top of = what the RS returned in (2b), since this is passed simply as one element = of the array.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha > wrote: >>>=20 >>> Hello Dick, >>>=20 >>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt > wrote: >>> Hi Francis >>>=20 >>> The user is an entity, not a role in the protocol in how I am = defining roles, so steps (1) and (7) are confusing to me on what is = happening. >>> "Requestor" is the role (was User). So the UML participant refers to = the role "Requestor" >>>=20 >>>=20 >>> I also think that (2) could be an extension to GNAP, rather than = part of the core protocol. >>> If you make it an extension, you hide. It shall rather be an = optional, integral part of the protocol. If the = "Orchestrator/Negotiator/Client" can translate the service request into = a resource request, then there will be no need to invoke (2). >>>=20 >>> When we move beyond identity management, cases become complex and it = makes sense to explicitly display this possibility in the protocol flow. >>>=20 >>> In some open banking designs,=20 >>> - the "Orchestrator/Negotiator/Client" will not know the AS to talk = to unless the call (2). >>> - the request (2) might result in an exemption, meaning no need for = further authorization, allowing to skip (3, 4, 5) and even (6). >>>=20 >>> /Francis >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha > wrote: >>> In this context, I suggest we pick some words to work with, and = sharpen them as we move on, discover and map new use cases to the = protocol. >>>=20 >>> In this diagram from the original thread = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ), I replaced the words: >>>=20 >>> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >>> | Requestor | | Orchestrator | | | | GS | | Resource = Controller | >>> | was | | was | | RS | | or | | was = | >>> | User | | Client | | | | AS | | Resource = Owner | >>> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >>> |(1) ServiceRequest | | | | >>> |---------------------->| | | | >>> | |(2) ServiceIntent:AuthZChallenge | >>> | |<---------->| | | >>> | | | | | >>> | |(3) AuthZRequest(AuthZChallenge) | >>> | |------------------->| | >>> | | | |(4) = ConsentRequest:Grant >>> | | | |<-------------->| >>> | |(5) GrantAccess(AuthZ) | >>> | |<-------------------| | >>> | | | | | >>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>> | |<---------->| | | >>> |(7) ServiceResponse | | | | >>> |<----------------------| | | | >>> + + + + + >>>=20 >>> The purpose of the GNAP protocol is to help negotiate access to a = protected resource. It starts with a requestor delegating activity to an = orchestrator. These are all roles, no entities. Let focus on mapping the = use cases to the protocol roles and interactions so wwe can discover = what is missing. >>>=20 >>> It seems cumbersome to use it in discussions as it is impossible to = give the word "Client" a clear definition. >>>=20 >>> We can mention in the final document, that the "Orchestrator" (or = whatever word we finally use) plays the same role as the "Client" in = oAuth2. >>>=20 >>> Best regards. >>> /Francis >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt > wrote: >>> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>>=20 >>> Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>>=20 >>> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>>=20 >>> /Dick >>> =E1=90=A7 >>>=20 >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>=20 >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>>>=20 >>>> I think that is fundamentally part of the question: >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>> confusion >>>>=20 >>>> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>>>=20 >>>> Food for thought. >>>> - Warren >>>>=20 >>>>=20 >>>> Warren Parad >>>> Founder, CTO >>>> Secure your user data and complete your authorization architecture. = Implement Authress . >>>>=20 >>>>=20 >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>>> Hi Denis, >>>>=20 >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> >=20 >>>> > Since you replied in parallel, I will make a response similar to = the one=20 >>>> > I sent to Dick. >>>> >=20 >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >>>> > > you describe as RS2, which might in fact be an RS unto itself, = is a=20 >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >>>> > > all the same as an OAuth client. I appreciate your mapping of = the=20 >>>> > > entities below, but it makes it difficult to hold a discussion = if we=20 >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,=20 >>>> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >>>> >=20 >>>> > In the ISO context, each document must define its own = terminology. The=20 >>>> > boiler plate for RFCs does not mandate a terminology or = definitions section >>>> > but does not prevent it either. The vocabulary is limited and as = long as=20 >>>> > we clearly define what our terms are meaning, we can re-use a = term already >>>> > used in another RFC. This is also the ISO approach. >>>>=20 >>>> Just because we can do something does not necessarily mean that it = is a >>>> good idea to do so. We are clear that we are producing a protocol = that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted = Dick to >>>> use the term "GS" in XAuth, picking a name that was not already = used in >>>> OAuth 2.0. >>>>=20 >>>> -Ben >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>>=20 >>> --=20 >>> Francis Pouatcha >>> Co-Founder and Technical Lead >>> adorsys GmbH & Co. KG >>> https://adorsys-platform.de/solutions/ = >>>=20 >>> --=20 >>> Francis Pouatcha >>> Co-Founder and Technical Lead >>> adorsys GmbH & Co. KG >>> https://adorsys-platform.de/solutions/ = >=20 --Apple-Mail=_1AC4C4AE-D5CE-4956-BEEF-8186A06A3CEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis,

This= isn=E2=80=99t mandated, this is one optional flow for the cases where = the RS :wants: to talk to the AS. 

 =E2=80=94 Justin

On Aug 12, 2020, at 12:02 PM, Denis <denis.ietf@free.fr> = wrote:

=20
Justin,

A soon as the RS needs to talk to the GS (step 2a) , it is a "Big Brother by Design" architecture.
Do you want to mandate it ?

Denis

=20 +1 to this. I think that the core protocol needs to be designed to allow this kind of action, but I also think it is possible that the details of this could end up in an extension to the main document. I=E2=80=99ve put a flag in the ground for this in XYZ in sections 10.3 and 10.4, which is adapted from UMA2=E2=80=99s = distributed authorization protocol:

https://tools.ietf.org/html/draft-richer-transact= ional-authz-09#section-10.3

The important detail here, in XYZ=E2=80=99s = design, is that the RS has a clear way to communicate to the client what will be needed to fulfill the request, and the client/orchestrator/whatever has a clear way to incorporate that into the main protocol. The details of (2) using the XYZ pattern are:

+-----------+      +--------------+  +----+  +----+ =  +---------------------+
| Requestor |      | Orchestrator | =  |    |  | GS |  | Resource Controller |
|  =  was     |      |     was      |  = | RS |  | or |  |        =  was         |
|  = User     |      |   Client     |  |  =   |  | AS |  |    Resource Owner  =  |
+-----------+      +--------------+ =  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |    =         |       |    =             |
  |---------------------->|      =       |       |      =           |
  |              =          |(2) = ServiceIntent:AuthZChallenge     |
  |              =          |----------->|      =  |                |
  | =                       |         =    |       |           =      |
  | =                       |         =    |(2a) Register resource set
  |                =        |            = |------>|                |
  = |                       |    =         |       |    =             |
  = |                       |    =         |(2b) Return resource reference handle
=   = |                       |    =         |<------|        =         |
  = |                       |    =         |       |    =             |
  = |                       |(2c) Return AS URL = and resource reference handle
  = |                      =  |<-----------|       |      =           |
  = |                       |    =         |       |    =             |
  |    =                   =  |(3) AuthZRequest(AuthZChallenge, include resource handle)
  |              =          |------------------->|    =             |


Note that the client can ALSO request additional resources on top of what the RS returned in (2b), since this is passed simply as one element of the array. 

 =E2=80=94 Justin

On Aug 11, 2020, at 6:37 PM, Francis = Pouatcha <fpo@adorsys.de> wrote:

=20
Hello Dick,

On Tue, Aug 11, = 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role = in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). So the UML participant refers to the = role "Requestor"


I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol. If the "Orchestrator/Negotiator/Client" can translate the service request into a resource request, then there will be no need to invoke = (2).

When we move beyond identity = management, cases become complex and it makes sense to explicitly display this possibility in the protocol flow.

In some open banking = designs, 
- the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call = (2).
- the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

/Francis





On Mon, Aug = 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread = (https://mailarchive.ietf.org/arch/msg/txauth/IaSL= C_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+ =  +----+  +----+  +---------------------+
= | Requestor |      | = Orchestrator |  |    |  | GS |  | Resource Controller = |
|   was     |  =     |     was      |  = | RS |  | or |  |      =    was         |
|  User     |    =   |   Client     |  |    = |  | AS |  |    Resource = Owner   |
+-----------+      = +--------------+  +----+  +----+ =  +---------------------+
  |(1) ServiceRequest    =  |            |       |      =           |
  |---------------------->|  =           |       |    =             |
  |          =              |(2) ServiceIntent:AuthZChallenge    =  |
  |          =              |<---------->|    =    |                |
  |          =              |      =       |       |      =           |
  |          =              |(3) AuthZRequest(AuthZChallenge)    =  |
  |          =              |------------------->|  =               |
  |          =              |      =       |       |(4) = ConsentRequest:Grant
  |          =              |      =       |      =  |<-------------->|
  |          =              |(5) GrantAccess(AuthZ)      =          |
  |          =              |<-------------------|  =               |
  |          =              |      =       |       |      =           |
  |          =              |(6) ServiceRequest(AuthZ):ServiceResponse
  |          =              |<---------->|    =    |                |
  |(7) ServiceResponse    = |            |       |      =           |
  |<----------------------|  =           |       |    =             |
  +          =              +      =       +       +      =           +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, = that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, = Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I agree with = Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should = have a name not being used already in OAuth or OIDC.

Given what we have = learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

For example, clarifying = that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""=E1=90=A7

On = Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I=E2=80=99m in favor of = coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of = taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up = with a new, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80= =9D as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to = =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term = =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2=80= =9D on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2=80= =9D and =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore the fact = that GNAP is going to be coming up in a world that is already permeated =  by OAuth 2 and its terminology. We don=E2=80=99t have a blank slate to = work with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a = delicate balance!

 =E2=80=94 = Justin

On Aug 4, = 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think = that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to = unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- = Warren
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. = Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a = problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2= =80=9D in OAuth parlance because it is /a client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80= =9D has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t = using the same terms.
> >
> > The good news is that this isn=E2=80=99t= OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just = re-use existing terms with new definitions,
> > but we=E2=80=99v= e got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do = so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to = unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">


--
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/



= --Apple-Mail=_1AC4C4AE-D5CE-4956-BEEF-8186A06A3CEB-- From nobody Wed Aug 12 09:57:19 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 6AE9D3A148A for ; Wed, 12 Aug 2020 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8aGlvaLaGet5 for ; Wed, 12 Aug 2020 09:57:04 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5203A13DD for ; Wed, 12 Aug 2020 09:57:02 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CGutfR012934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 12:56:55 -0400 From: Justin Richer Message-Id: <6A303E35-2D2F-4182-AAF8-46269EAC4E5E@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_493EB2CD-232F-425E-A65C-FBD1122CD3B7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 12:56:55 -0400 In-Reply-To: Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Fabien Imbault , Denis , "txauth@ietf.org" To: Dick Hardt References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Terminology 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: Wed, 12 Aug 2020 16:57:17 -0000 --Apple-Mail=_493EB2CD-232F-425E-A65C-FBD1122CD3B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would disagree with this definition regardless of who proposed it. = Please, do not make this personal. It isn=E2=80=99t for me. =E2=80=94 Justin > On Aug 12, 2020, at 12:40 PM, Dick Hardt wrote: >=20 > What is being granted is whatever is being negotiated between the = Grant Server and the Grant Client -> Which fits into the name of the WG, = Grant Negotiation and Authorization Protocol, allows us to have names = that are specific and precise for the roles (Grant Server and Grant = Client rather than Requesting Party), and is usable by an extension that = wants to negotiate some new thing between the two roles.=20 >=20 > I introduced the term "Grant" in XAuth to mean what the client = requested, and what the "server" provided, which included both resource = access and identity claims. You are narrowly defining grant to ONLY mean = "access to something". Sometimes I think you just want to disagree with = me. :) >=20 > I'd be interested in hearing from others! >=20 >=20 >=20 > In the current drafts, that is resource access and identity claims.=20 >=20 > =E1=90=A7 >=20 > On Wed, Aug 12, 2020 at 8:58 AM Justin Richer > wrote: > What is being granted is access to something. This makes sense in = terms of rights bound to an access token, but I would argue it makes = less sense for things returned directly. >=20 > Since you and I also disagree on whether returning things directly is = an important distinction (even though both the XAuth and XYZ proposals = make this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d = want to extend the notion of =E2=80=9Cgrant=E2=80=9D to include anything = and everything in the request and response.=20 >=20 > I am arguing for it being more specific and precise. >=20 > =E2=80=94 Justin >=20 >> On Aug 11, 2020, at 6:08 PM, Dick Hardt > wrote: >>=20 >> A grant is whatever the client is asking from the server. Currently = we have access to resources and identity claims. It could contain = anything else an extension adds that a client may request from a server. >>=20 >> Given the definition of grant that I included, why is grant not the = right term to use for this? >>=20 >>=20 >> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer > wrote: >> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I = said that your definition of it was problematic. Namely, the desire to = lump in claims about the user into the definition of the =E2=80=9Cgrant=E2= =80=9D.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Aug 11, 2020, at 3:49 PM, Dick Hardt > wrote: >>>=20 >>> I agree that orchestrator may be a role in the protocol -- it is not = a role in XYZ or XAuth today. >>>=20 >>> Justin: would you explain why you think the term "grant" is = problematic? It is in the WG name! >>>=20 >>> The client is receiving more than access to resources from the GS, = it is also receiving claims, so "client of the resource" is too = limiting. >>>=20 >>> Reading the definition of grant[1], it fits as a verb of what the GS = is doing, and fits as a noun of what the GS provides to the client. >>>=20 >>> A Grant Server is an Authorization Server in OAuth, and an OpenID = Provider in OpenID Connect. >>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID = Connect. >>>=20 >>> Having new terms (GS and GC) in GNAP, separating the roles from = OAuth and OpenID Connect. >>> It is straightforward to know what a GC and GS do when you = understand that a grant is a combination of resource access (from OAuth) = and claims (from OpenID Connect). >>>=20 >>> /Dick >>>=20 >>> [1] https://www.dictionary.com/browse/grant = >>> verb (used with object) >>> to bestow or confer, especially by a formal act: >>> to grant a charter. >>> to give or accord: >>> to grant permission. >>> to agree or accede to: >>> to grant a request. >>> to admit or concede; accept for the sake of argument: >>> I grant that point. >>> SEE MORE >>> noun >>> something granted, as a privilege or right, a sum of money, or a = tract of land: >>> Several major foundations made large grants to fund the research = project. >>> the act of granting. >>>=20 >>>=20 >>> [1]=20 >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer > wrote: >>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what = the classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but = the term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser = agent=E2=80=9D concept that=E2=80=99s been brought up here before, so = I=E2=80=99m inclined to believe it can be a separate role from the = client. >>>=20 >>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing = as it is not a =E2=80=9Cclient of the grant=E2=80=9D but rather a = =E2=80=9Cclient of the resource=E2=80=9D. >>>=20 >>> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt > wrote: >>>>=20 >>>> I echo Mike's comments on preserving names when possible. The shift = from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >>>>=20 >>>> I also echo Tom's comments about separating Entities from Roles. >>>>=20 >>>> Orchestration[1] in my opinion is not what the "client" is doing. >>>>=20 >>>> Below is a stab at separating the entities and the roles >>>>=20 >>>> /Dick >>>>=20 >>>> Tl;dr:=20 >>>> - Client -> Grant Client >>>> - added Relying Party, Claims Issuer, and Grant Server Operator as = entities >>>>=20 >>>> Roles - parties to the protocol >>>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>>=20 >>>> Entities - parties to a Trust Framework >>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server = Operator (GSO), Resource Owner (RO) >>>>=20 >>>> Grant - may contain claims and/or access to resources >>>>=20 >>>> #Protocol Roles >>>>=20 >>>> Grant Client (GC) >>>> - used by User >>>> - operated / provided by RP >>>> - requests Grants from the GS >>>> - access resources at an RS >>>> - consumes Claims >>>>=20 >>>> Grant Server (GS) >>>> - operated by GSO >>>> - may interact with the User=20 >>>> - may interact with the RO >>>> - accepts grant requests from GCs >>>> - issues grants to GCs >>>> - may issue claims >>>>=20 >>>> Resource Server (RS) >>>> - manages access to resources for the RO >>>> - provides access to resources for the GC >>>> - accepts access granted by the GS >>>>=20 >>>> #Legal Entities >>>>=20 >>>> User >>>> - uses Grant Client >>>> - may interact with the Grant Server >>>> - may also be a RO >>>> - trusts RP, Issuer, GSO >>>>=20 >>>> Relying Party (RP) >>>> - provides Grant Client to the User. >>>> - may trust Issuers, GSOs, and ROs >>>>=20 >>>> Claims Issuer (Issuer) >>>> - issues claims to RP >>>> - may use GS or RS to issue claims >>>>=20 >>>> Grant Server Operator (GSO) >>>> - operates the GS >>>> - trusted by User, RP, and RO >>>> - may also be an Issuer >>>>=20 >>>> Resource Owner (RO) >>>> - owns resources at the RS >>>> - trusts GSO to control access to the resources >>>> - may be same entity as the User >>>> - may also be an Issuer >>>>=20 >>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) = >>>>=20 >>>> Orchestration (computing) >>>> =46rom Wikipedia, the free encyclopedia >>>> Jump to navigation >>>> = Jump to = search >>>> = In = system administration = , orchestration is = the automated configuration = , coordination, = and management of computer systems and software = .[1] = >>>> A number of tools exist = for = automation of server configuration and management, including Ansible = , Puppet = , Salt = , Terraform = ,[2] = = and AWS CloudFormation = .[3] = >>>> Usage[edit = ] >>>> Orchestration is often discussed in the context of service-oriented = architecture = , = virtualization , = provisioning , converged = infrastructure = and dynamic datacenter = topics. Orchestration in this sense is about aligning the business = request with the applications, data, and infrastructure.[4] = >>>> In the context of cloud computing = , the main difference = between workflow automation = and orchestration is = that workflows are processed and completed as processes within a single = domain for automation purposes, whereas orchestration includes a = workflow and provides a directed action towards larger goals and = objectives.[1] = >>>> In this context, and with the overall aim to achieve specific goals = and objectives (described through quality of service = parameters), for = example, meet application performance goals using minimized cost[5] = and maximize application performance within budget = constraints.[6] = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones = > = wrote: >>>> One of the things that people hated about OAuth was it invented new = terminology that wasn=E2=80=99t in common use. But for better or for = worse, the terms Client, Authorization Server, and Protected Resource = are now widely understood. >>>>=20 >>>> =20 >>>>=20 >>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even = more novel terms, when existing terms will fit the bill. Client = wasn=E2=80=99t a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D = to the vocabulary menagerie would definitely make things worse. >>>>=20 >>>> =20 >>>>=20 >>>> -- Mike >>>>=20 >>>> =20 >>>>=20 >>>> From: TXAuth > On Behalf Of Tom Jones >>>> Sent: Tuesday, August 11, 2020 8:44 AM >>>> To: Dave Tonge > >>>> Cc: Francis Pouatcha >; = Justin Richer >; Dick Hardt = >; Benjamin Kaduk = >; Fabien Imbault = >; Denis = >; txauth@ietf.org = >>>> Subject: Re: [GNAP] Terminology >>>>=20 >>>> =20 >>>>=20 >>>> the term "orchestator" does not match any use case i have. >>>>=20 >>>> Let's be clear that there are four entities to a single transaction = in the real world sense of things. (and others that support the = transaction.) >>>>=20 >>>> Then we can focus on the end point roles. I will focus on the data = privacy issues, API's have the same parties with different terminology. >>>>=20 >>>> 1. the subject of the data to be transferred. >>>>=20 >>>> 2. the user of a grant from the subject to act as delegate. (see = https://wiki.idesg.org/wiki/index.php/Delegation = for how to enable the = user) >>>>=20 >>>> 3. the site that has a repository of user data with legal = obligations to protect that data (the GDPR) (role resource server.) >>>>=20 >>>> 4 the site that wants either access to the data, or some privacy = preserving statement about the existence and content of the data. (role = of client, vendor, PISP, etc.) >>>>=20 >>>> 5. some sorts of facilitator sites for allowing access (roles like = authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left out of OAUTH for good reason. >>>>=20 >>>> =20 >>>>=20 >>>> This is a note supporting the separation of roles from legal = entities. BTW, I firmly believe that the legal entity also needs to be = ID'd by the transaction. >>>>=20 >>>> Peace ..tom >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: >>>>=20 >>>> Hi all >>>>=20 >>>> =20 >>>>=20 >>>> I agree that "client" can be confusing. I would be in support of = alternative terminology. >>>>=20 >>>> We can always have some wording that explains that an = "Orchestrator" in GNAP plays a similar role to "Client" in OAuth. >>>>=20 >>>> =20 >>>>=20 >>>> Dave >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault = > wrote: >>>>=20 >>>> Hi Francis, >>>>=20 >>>> =20 >>>>=20 >>>> I like your proposal, seems much more intuitive.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> =20 >>>>=20 >>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = > a =C3=A9crit : >>>>=20 >>>> Hello Denis, Justin, Dick, Fabien, >>>>=20 >>>> =20 >>>>=20 >>>> In this post = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ) i suggested we use the word "Orchestrator" to designate the piece of = software that orchestrate interaction between "Requestor" (a.k.a. User), = AS and RS to obtain the protected resource.=20 >>>>=20 >>>> =20 >>>>=20 >>>> We are turning around the same topic. As soon as we go beyond the = original oAuth protocol, the word 'Client' becomes confusing. >>>>=20 >>>> =20 >>>>=20 >>>> In the same response, I suggest we talk about "roles" and not = "entities". >>>>=20 >>>> =20 >>>>=20 >>>> Best regards. >>>>=20 >>>> /Francis >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > wrote: >>>>=20 >>>> I still think that client was the right name in OAuth 2, as the = client wanted to do a client-server interaction, so the client used = OAuth 2 to get an access token to interact with the "server". >>>>=20 >>>> =20 >>>>=20 >>>> I do agree that it is not the best term in GNAP. Primarily because = GNAP is a combination of the client from OAuth 2, and the relying party = from OIDC.=20 >>>>=20 >>>> =20 >>>>=20 >>>> /Dick >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > wrote: >>>>=20 >>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt > wrote: >>>>=20 >>>> =20 >>>>=20 >>>> The term client in OAuth came from the computer science definition = of client-server interaction. >>>>=20 >>>> =20 >>>>=20 >>>> This, I would argue, is exactly why it=E2=80=99s a bad label for = something that=E2=80=99s distinctly more specific in this context, and I = would love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth. >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> The client is getting an access token so it can call a server, = specifically, a resource server (to differentiate it from the = authorization server). >>>>=20 >>>> =20 >>>>=20 >>>> The confusion in my experience usually stems from people working = with software that is acting in multiple roles. IE, the software that is = acting as a client in once context, is also acting as an RS in other = contexts, or even acting as an AS. The other confusion is that people = view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault = > wrote: >>>>=20 >>>> Hi,=20 >>>>=20 >>>> =20 >>>>=20 >>>> To me, client has always been a strange word in the context of = OAuth, as it has a meaning well defined both in everyday life (this = client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the = OAuth world before any discussion... And any teaching experience shows = that it does make the concepts hard to grasp for a majority of (clever) = people. >>>>=20 >>>> =20 >>>>=20 >>>> As for the RO, previous discussions suggested Resource Controller = (RC) also, which may be a bit more specific than manager.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 1:00 PM Denis > wrote: >>>>=20 >>>> Justin and Dick, >>>>=20 >>>> =20 >>>>=20 >>>> [Was: "Revisiting the photo sharing example (a driving use case = for the creation of OAuth)"] >>>>=20 >>>> =20 >>>>=20 >>>> So let us attempt to define new terms: >>>>=20 >>>> initiating application (IA): application by means of which a user = initiates interactions with RS(s) and AS(s) >>>>=20 >>>> In the same way, we should get rid of the term Resource Owner (RO), = which is currently defined as: >>>>=20 >>>> Resource Owner (RO): entity capable of granting access to a = protected resource >>>>=20 >>>> I propose to replace it with Resource Manager (RM): >>>>=20 >>>> Resource Manager (RM) : application or user that manages an access = decision function of a Resource Server >>>>=20 >>>> Denis >>>>=20 >>>> =20 >>>>=20 >>>> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>>>=20 >>>> =20 >>>>=20 >>>> Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>>>=20 >>>> =20 >>>>=20 >>>> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>>>=20 >>>> =20 >>>>=20 >>>> /Dick >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> =20 >>>>=20 >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >>>>=20 >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>=20 >>>> =20 >>>>=20 >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>>>=20 >>>> =20 >>>>=20 >>>> I think that is fundamentally part of the question: >>>>=20 >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>> confusion >>>>=20 >>>> =20 >>>>=20 >>>> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>>>=20 >>>> =20 >>>>=20 >>>> Food for thought. >>>>=20 >>>> - Warren >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Warren Parad >>>>=20 >>>> Founder, CTO >>>>=20 >>>> Secure your user data and complete your authorization architecture. = Implement Authress . >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>>>=20 >>>> Hi Denis, >>>>=20 >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> >=20 >>>> > Since you replied in parallel, I will make a response similar to = the one=20 >>>> > I sent to Dick. >>>> >=20 >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >>>> > > you describe as RS2, which might in fact be an RS unto itself, = is a=20 >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >>>> > > all the same as an OAuth client. I appreciate your mapping of = the=20 >>>> > > entities below, but it makes it difficult to hold a discussion = if we=20 >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,=20 >>>> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >>>> >=20 >>>> > In the ISO context, each document must define its own = terminology. The=20 >>>> > boiler plate for RFCs does not mandate a terminology or = definitions section >>>> > but does not prevent it either. The vocabulary is limited and as = long as=20 >>>> > we clearly define what our terms are meaning, we can re-use a = term already >>>> > used in another RFC. This is also the ISO approach. >>>>=20 >>>> Just because we can do something does not necessarily mean that it = is a >>>> good idea to do so. We are clear that we are producing a protocol = that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted = Dick to >>>> use the term "GS" in XAuth, picking a name that was not already = used in >>>> OAuth 2.0. >>>>=20 >>>> -Ben >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> Francis Pouatcha >>>>=20 >>>> Co-Founder and Technical Lead >>>>=20 >>>> adorsys GmbH & Co. KG >>>>=20 >>>> https://adorsys-platform.de/solutions/ = >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>>>=20 >>>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>>=20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 --Apple-Mail=_493EB2CD-232F-425E-A65C-FBD1122CD3B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would disagree with this definition regardless of who proposed it. = Please, do not make this personal. It isn=E2=80=99t for me.
 =E2=80=94 = Justin

On Aug 12, 2020, at 12:40 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

What is being granted is whatever = is being negotiated between the Grant Server and the Grant Client -> = Which fits into the name of the WG, Grant Negotiation and Authorization = Protocol, allows us to have names that are specific and precise for the = roles (Grant Server and Grant Client rather than Requesting Party), and = is usable by an extension that wants to negotiate some new thing between = the two roles. 

I= introduced the term "Grant" in XAuth to mean what the client requested, = and what the "server" provided, which included both resource access and = identity claims. You are narrowly defining grant to ONLY mean "access to = something". Sometimes I think you just want to disagree with me. = :)

I'd be = interested in hearing from others!



In the = current drafts, that is resource access and identity = claims. 

3D""=E1=90=A7

On Wed, Aug = 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
What is being granted is access to something. = This makes sense in terms of rights bound to an access token, but I = would argue it makes less sense for things returned directly.

Since you and I also = disagree on whether returning things directly is an important = distinction (even though both the XAuth and XYZ proposals make this = distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d want to = extend the notion of =E2=80=9Cgrant=E2=80=9D to include anything and = everything in the request and response. 

I am arguing for it being more specific = and precise.

 =E2=80=94 Justin

On Aug = 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

A grant is whatever the client is = asking from the server. Currently we have access to resources and = identity claims. It could contain anything else an extension adds that a = client may request from a server.

Given the definition of grant that I included, why is grant = not the right term to use for this?


On Tue, Aug 11, 2020 at 1:35 PM Justin = Richer <jricher@mit.edu> wrote:
I did not say = the term =E2=80=9Cgrant=E2=80=9D was problematic, I said that your = definition of it was problematic. Namely, the desire to lump in claims = about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. 
 =E2=80=94 = Justin

On Aug 11, 2020, at 3:49 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be = a role in the protocol -- it is not a role in XYZ or XAuth today.

Justin: would you = explain why you think the term "grant" is problematic? It is in the WG = name!

The = client is receiving more than access to resources from the GS, it = is also receiving claims, so "client of the resource" is too = limiting.

Reading the definition of grant[1], it fits as a verb of what = the GS is doing, and fits as a noun of what the GS provides to the = client.

A = Grant Server is an Authorization Server in OAuth, and an OpenID Provider = in OpenID Connect.
The Grant Client is a Client in = OAuth, and a Relying Party in OpenID Connect.

Having new terms (GS and GC) in GNAP, = separating the roles from OAuth and OpenID Connect.
It is straightforward to know what a GC and GS do when = you understand that a grant is a combination of resource access = (from OAuth) and claims (from OpenID Connect).

/Dick

[1] https://www.dictionary.com/browse/grant

verb (used with = object)

to bestow or confer, especially by a formal act:to grant a = charter.
to give or accord:to grant = permission.
to agree or accede to:to grant a = request.
to admit or concede; accept for the sake of argument:I grant that = point.

noun

something granted, as a privilege or right, a sum of money, = or a tract of land:Several major foundations made large = grants to fund the research project.
the act of granting.


[1] 



On Tue, Aug = 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that = =E2=80=9Corchestration=E2=80=9D is separate from what the classical = =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term = =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D = concept that=E2=80=99s been brought up here before, so I=E2=80=99m = inclined to believe it can be a separate role from the client.

I personally think that = =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient= of the grant=E2=80=9D but rather a =E2=80=9Cclient of the = resource=E2=80=9D.

I also think it=E2=80=99s problematic to lump in user claims = with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything. 

 =E2=80=94 Justin

On Aug = 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comments on = preserving names when possible. The shift from "consumer" in OAuth 1 to = "client" in OAuth 2 was confusing to many.

I also echo Tom's = comments about separating Entities from Roles.

Orchestration[1] in my opinion is not = what the "client" is doing.

Below is a stab at separating the entities and the = roles

/Dick

Tl;dr: 
- = Client -> Grant Client
- added Relying = Party, Claims Issuer, and Grant Server Operator as entities

Roles - parties to the protocol
Grant = Client (GC), Grant Server (GS), Resource Server (RS)

Entities - parties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant = Server Operator (GSO), Resource Owner (RO)

Grant - may contain claims and/or = access to resources

#Protocol Roles

Grant Client = (GC)
- used by User
- operated = / provided by RP
- requests Grants from the = GS
- access resources at an RS
-= consumes Claims

Grant Server (GS)
- = operated by GSO
- may interact with the = User 
- may interact with the RO
- accepts grant requests from GCs
- = issues grants to GCs
- may issue claims

Resource = Server (RS)
- manages access to resources for = the RO
- provides access to resources for the = GC
- accepts access granted by the GS

#Legal = Entities

User
- uses Grant Client
- may interact with the Grant Server
- = may also be a RO
- trusts RP, Issuer, GSO

Relying = Party (RP)
- provides Grant Client to the User. =
- may trust Issuers, GSOs, and ROs

Claims = Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant Server Operator = (GSO)
- operates the GS
- = trusted by User, RP, and RO
- may also be an = Issuer

Resource Owner (RO)
- = owns resources at the RS
- trusts GSO to control = access to the resources
- may be same entity as the = User
- may also be an = Issuer

[1] https://en.wikipedia.org/wiki/Orchestration_(computing)

Orchestration (computing)

=46rom = Wikipedia, the free encyclopedia
Jump to navigationJump to search
In system administration, orchestration is the automated configuration, coordination, and = management of computer systems and software.[1]
A number of tools exist for = automation of server configuration and management, including Ansible, Puppet, Salt, Terraform,[2] and AWS CloudFormation.[3]

Usage[edit]

Orchestration is often discussed in the context of service-oriented architecture, virtualization, provisioning, converged infrastructure and = dynamic datacenter topics. Orchestration = in this sense is about aligning the business request with the = applications, data, and infrastructure.[4]
In the context of cloud computing, the main difference = between workflow automation and = orchestration is that workflows are processed and completed as processes = within a single domain for automation purposes, whereas orchestration = includes a workflow and provides a directed action towards larger goals = and objectives.[1]
In this context, and with the overall aim to achieve = specific goals and objectives (described through quality of service parameters), = for example, meet application performance goals using minimized cost[5] and maximize application = performance within budget constraints.[6]








On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the things that people hated about OAuth was it = invented new terminology that wasn=E2=80=99t in common use.  But = for better or for worse, the terms Client, Authorization Server, and = Protected Resource are now widely understood.

 

Let=E2=80= =99s not make people similarly hate GNAP by inventing even more novel = terms, when existing terms will fit the bill.  Client wasn=E2=80=99t = a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the = vocabulary menagerie would definitely make things worse.

 

          &nb= sp;   =             &n= bsp;           &nbs= p;            =     -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

 

the term "orchestator" does not = match any use case i have.

Let's be clear that there are = four entities to a single transaction in the real world sense of things. = (and others that support the  transaction.)

Then we can focus on the end = point roles. I will focus on the data privacy issues, API's have the = same parties with different terminology.

1. the subject of the data to be = transferred.

2. the user of a grant from the = subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how = to enable the user)

3. the site that has a repository = of user data with legal obligations to protect that data (the GDPR) = (role resource server.)

4 the site that wants either = access to the data, or some privacy preserving statement about the = existence and content of the data. (role of client, vendor, PISP, = etc.)

5. some sorts of facilitator = sites for allowing access (roles like authenticator, idp, verifier, csp, = RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

 

This is a note supporting the = separation of roles from legal entities.  BTW, I firmly believe = that the legal entity also needs to be ID'd by the transaction.

Peace ..tom

 

 

On Tue, Aug 11, 2020 at 1:42 AM = Dave Tonge <dave.tonge@moneyhub.com> wrote:

Hi = all

 

I = agree that "client" can be confusing. I would be in support of = alternative terminology.

We = can always have some wording that explains that an "Orchestrator" in = GNAP plays a similar role to "Client" in OAuth.

 

Dave

 

On Tue, 11 Aug 2020 at 07:52, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Francis,

 

I like your proposal, seems much = more intuitive. 

 

Fabien 

 

Le mar. 11 ao=C3=BBt 2020 =C3=A0 = 04:17, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit :

Hello Denis, Justin, Dick, = Fabien,

 

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between = "Requestor" (a.k.a. User), AS and RS to obtain the protected = resource. 

 

We are turning around the same = topic. As soon as we go beyond the original oAuth protocol, the = word 'Client' becomes confusing.

 

In the same response, I = suggest we talk about "roles" and not "entities".

 

Best regards.

/Francis

 

On Thu, Aug 6, 2020 at 6:36 PM = Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the = right name in OAuth 2, as the client wanted to do a client-server = interaction, so the client used OAuth 2 to get an access token to = interact with the "server".

 

I do agree that it is not the = best term in GNAP. Primarily because GNAP is a combination of the client = from OAuth 2, and the relying party from OIDC. 

 

/Dick

=E1=90=A7

 

On Thu, Aug 6, 2020 at 12:50 PM = Justin Richer <jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

 

The term client in OAuth came = from the computer science definition of client-server interaction.

 

This, I would argue, is exactly = why it=E2=80=99s a bad label for something that=E2=80=99s distinctly = more specific in this context, and I would love to see GNAP adopt a more = specific label for the role that we traditionally called =E2=80=9Cclient=E2= =80=9D in OAuth.

 

 =E2=80=94 Justin



 

The client is getting an access = token so it can call a server, specifically, a resource server (to = differentiate it from the authorization server).

 

The confusion in my experience = usually stems from people working with software that is acting = in multiple roles. IE, the software that is acting as a client = in once context, is also acting as an RS in other contexts, or even = acting as an AS. The other confusion is that people view clients as being the = software the user is using -- although it may not be acting as a client = in the oauth context.

 

 

 

=E1=90=A7

 

On Thu, Aug 6, 2020 at 4:49 AM = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

 

To me, client has always been a = strange word in the context of OAuth, as it has a meaning well defined = both in everyday life (this client is a good customer) and in computer = science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And = any teaching experience shows that it does make the concepts hard to = grasp for a majority of (clever) people.

 

As for the RO, previous = discussions suggested Resource Controller (RC) also, which may = be a bit more specific than manager. 

 

Fabien 

 

On Thu, Aug 6, 2020 at 1:00 PM = Denis <denis.ietf@free.fr> wrote:

Justin and = Dick,

 

[Was:  = "Revisiting the photo sharing example (a driving use case for the = creation of OAuth)"]

 

So let us attempt to = define new terms:

initiating application = (IA): = application by means of which a user initiates interactions with RS(s) = and AS(s)

In the same way, we = should get rid of the term Resource Owner (RO), which is currently = defined as:

Resource Owner (RO): = entity capable of granting access to a protected resource

I propose to replace = it with Resource Manager (RM):

Resource Manager = (RM) = : application or user that manages an access decision function of a = Resource Server

Denis

 

I agree with Justin. Redefining = well used terms will lead to significant confusion. If we have a = different role than what we have had in the past, then that role = should have a name not being used already in OAuth or OIDC.

 

Given what we have learned, and = my own experience explaining what a Client is, and is not, improving the = definition for Client could prove useful. I am not suggesting the term = be redefined, but clarified. 

=

 

For example, clarifying that a = Client is a role an entity plays in the protocol, and that the same = entity may play other roles at other times, or some other language to = help differentiate between "role" and "entity".

 

/Dick

=E1=90=A7

 

On Wed, Aug 5, 2020 at 8:20 AM = Justin Richer <jricher@mit.edu> wrote:

I=E2=80=99m in favor of coming up = with a new term that=E2=80=99s a better fit, but I=E2=80=99m not really = in favor of taking an existing term and applying a completely new = definition to it. In other words, I would sooner stop using =E2=80=9Cclien= t=E2=80=9D and come up with a new, more specific and accurate term for the role than to define = =E2=80=9Cclient=E2=80=9D as meaning something completely different. We = did this in going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizat= ion Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

 

GNAP can do something similar, in = my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is = going to be coming up in a world that is already permeated  by = OAuth 2 and its terminology. We don=E2=80=99t have a blank slate to work = with, but neither are we bound to use the same terms and constructs as before. = It=E2=80=99s going to be a delicate balance!

 

 =E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, = Warren Parad <wparad@rhosys.ch> wrote:

 

I think that is fundamentally = part of the question:

We are clear that we are producing a protocol that = is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

 

If we say that this document = assumes OAuth2.0 terminology, then we should not change the meanings of = any definition. If we are saying this supersedes or replaces what OAuth = 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand = experience of industries "ruining words", and attempting to side-step = the problem rather than redefining the word just confuses everyone as = everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious = word continues.

 

Food for thought.

- Warren

Warren = Parad

Founder, = CTO

Secure your user data and complete your authorization = architecture. Implement Authress.

 

 

On Tue, Aug 4, 2020 at 8:53 PM = Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

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

 

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

 

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

 

--
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/

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

 

 

Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number 06909772. = Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject = to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are = made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's = business. Any opinions expressed in this email (or in any attachments) = are those of the author and do not necessarily represent the opinions of = Moneyhub Financial Technology Limited or of any other group company.


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





= --Apple-Mail=_493EB2CD-232F-425E-A65C-FBD1122CD3B7-- From nobody Wed Aug 12 10:00:10 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 A58C73A1426 for ; Wed, 12 Aug 2020 10:00:02 -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 sHHzEGpLDjyM for ; Wed, 12 Aug 2020 09:59:58 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 6AAD73A141F for ; Wed, 12 Aug 2020 09:59:54 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id l7so2485447ils.2 for ; Wed, 12 Aug 2020 09:59:54 -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=6KM84R3+w9DFRwwVEOy/695pvherdfwMhy/92GCufpk=; b=kGGeV4yILNTNtZg6p4e9nHumPmbGgvWSBvW8Isl9dPJTKY/4hVVWTM8Y9aiRhfcQ++ DBUVPSnJe4r/T1pBS9To0WgGHp0b/nRhLfW+2JGd71y4B2a0i4xxKJGr1coGZqwELC5V nYLYA6vU2wzp1svfAVIK/ZF4+LUvxZUrgwjtCF88KVKkwYGC9935yrr6C/ub/chAa6s3 qGtOWOXZEWTUFQAHdBIEODVGyHMOJimXSTm5N1bDKJY0/rw3rlQl9sDfeutwRg/52lVD sk6iCggRMYRUnLdiVkW7JqOXvONKcTRpV1pfpUcQcP41XW+AQKCFZRiWwDHovBFDkCL5 HLdA== 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=6KM84R3+w9DFRwwVEOy/695pvherdfwMhy/92GCufpk=; b=gGf35VyzOeW5I/BHEoColsFH0dorIvT1Hcp00WD5Fnsqs4o5ablGBpArT0iFXLtYxC XffWAvdcYeBMRXH0p6cfotH+DeXmdQs7NeRWyL5x6JSh0km26rzdmtdISJtYd7VcqFAU jyKm0ehtpl3rlzU3LJbm2XuQa2zuVtfBZVEcwwg8QZp5BhmrL88Y/XefE+2wmWsi7+NM laroAccB+YlrzBLb+hGO7iPsVmJvDdd+rLFOK86yvYFCO4xR1NOJaN2Kbe2KqwAIyACD +l3b7exdKQBGumqD35oc1IWqRKzkuF2txBjEO7YmsHE4yfPi7ruuNYjhuZjDqfwRVC5V CjtQ== X-Gm-Message-State: AOAM531XjlQaX+rtpM69M7oX6Sy0q7VsscZ5Ia/jO2xPDXobujvHAwSJ 8bOi1OR9miGr2hRO2AWc/e8MZ1KgaQkBOz4NzS4= X-Google-Smtp-Source: ABdhPJycFqhF8f1bjdzIGtPMJbKmO62+Wsc0WnuVCiUJcQpq7nQ922be+kR7iod3jA/3y97E27tluRlTLPbNpQFhehk= X-Received: by 2002:a05:6e02:c09:: with SMTP id d9mr575250ile.289.1597251593554; Wed, 12 Aug 2020 09:59:53 -0700 (PDT) MIME-Version: 1.0 References: <63a40d80-e7b3-4016-d92c-f1889fe62dfe@free.fr> In-Reply-To: <63a40d80-e7b3-4016-d92c-f1889fe62dfe@free.fr> From: Fabien Imbault Date: Wed, 12 Aug 2020 18:59:42 +0200 Message-ID: To: Denis Cc: Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Justin Richer , Dick Hardt , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d9d15a05acb11ded" Archived-At: Subject: Re: [GNAP] Terminology 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: Wed, 12 Aug 2020 17:00:08 -0000 --000000000000d9d15a05acb11ded Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I agree with that process. Just as an additional reference (more related to identity), https://canada-ca.github.io/PCTF-CCP/PCTF.html demonstrates I think the importance of the terminology. In that case, they bring many useful definitions (appendix A). By the way, for them, client is "The intended recipient for a service output. External clients are generally persons (Canadian citizens, permanent residents, etc.) and businesses (public and private sector organizations). Internal clients are generally employees and contractors." Another example, less obvious: instead of authentication which is a very overloaded term, you end up with verification and validation for identity and credential (appendix D). Then of course one needs to find the right mix between reinventing the wheel (and the risk of making it hard to get into) and being specific enough. Fabien On Tue, Aug 11, 2020 at 7:25 PM Denis wrote: > To all, > > We are circling around. In order to progress about the terminology, I > propose the following: > > 1=C2=B0 Adopt the ISO rule for a definition: > > The definition shall be written in such a form that it can replace the > term in its context. > It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2= =80=9D) nor end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > 2=C2=B0 Propose at the same time a term AND its definition. > > 3=C2=B0 If you don't like a term or its definition proposed by someone el= se, > this is fine ... but only as long as > you have a counter proposal for either the term and/or its definition. As > an example, only stating that > " "client" can be confusing" would not be a valid proposal. > > Terms and definitions are used in the context of RFCs issued by a WG and > it is fine using terms > already used by other RFCs issued by another WG as long as we clearly > define them. > > Denis > > One of the things that people hated about OAuth was it invented new > terminology that wasn=E2=80=99t in common use. But for better or for wor= se, the > terms Client, Authorization Server, and Protected Resource are now widely > understood. > > > > Let=E2=80=99s not make people similarly hate GNAP by inventing even more = novel > terms, when existing terms will fit the bill. Client wasn=E2=80=99t a pe= rfect > choice but adding =E2=80=9COrchestrator=E2=80=9D to the vocabulary menage= rie would > definitely make things worse. > > > > -- Mike > > > > *From:* TXAuth *On > Behalf Of *Tom Jones > *Sent:* Tuesday, August 11, 2020 8:44 AM > *To:* Dave Tonge > *Cc:* Francis Pouatcha ; Justin Richer > ; Dick Hardt > ; Benjamin Kaduk ; > Fabien Imbault ; > Denis ; txauth@ietf.org > *Subject:* Re: [GNAP] Terminology > > > > the term "orchestator" does not match any use case i have. > > Let's be clear that there are four entities to a single transaction in th= e > real world sense of things. (and others that support the transaction.) > > Then we can focus on the end point roles. I will focus on the data privac= y > issues, API's have the same parties with different terminology. > > 1. the subject of the data to be transferred. > > 2. the user of a grant from the subject to act as delegate. (see > https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the > user) > > 3. the site that has a repository of user data with legal obligations to > protect that data (the GDPR) (role resource server.) > > 4 the site that wants either access to the data, or some privacy > preserving statement about the existence and content of the data. (role o= f > client, vendor, PISP, etc.) > > 5. some sorts of facilitator sites for allowing access (roles like > authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been le= ft > out of OAUTH for good reason. > > > > This is a note supporting the separation of roles from legal entities. > BTW, I firmly believe that the legal entity also needs to be ID'd by the > transaction. > > Peace ..tom > > > > > > On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: > > Hi all > > > > I agree that "client" can be confusing. I would be in support of > alternative terminology. > > We can always have some wording that explains that an "Orchestrator" in > GNAP plays a similar role to "Client" in OAuth. > > > > Dave > > > > On Tue, 11 Aug 2020 at 07:52, Fabien Imbault > wrote: > > Hi Francis, > > > > I like your proposal, seems much more intuitive. > > > > Fabien > > > > Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = a =C3=A9crit : > > Hello Denis, Justin, Dick, Fabien, > > > > In this post ( > https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= ) > i suggested we use the word "Orchestrator" to designate the piece of > software that orchestrate interaction between "Requestor" (a.k.a. User), = AS > and RS to obtain the protected resource. > > > > We are turning around the same topic. As soon as we go beyond the origina= l > oAuth protocol, the word 'Client' becomes confusing. > > > > In the same response, I suggest we talk about "roles" and not "entities". > > > > Best regards. > > /Francis > > > > On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt wrote: > > I still think that client was the right name in OAuth 2, as the client > wanted to do a client-server interaction, so the client used OAuth 2 to g= et > an access token to interact with the "server". > > > > I do agree that it is not the best term in GNAP. Primarily because GNAP i= s > a combination of the client from OAuth 2, and the relying party from OIDC= . > > > > /Dick > > =E1=90=A7 > > > > On Thu, Aug 6, 2020 at 12:50 PM Justin Richer wrote: > > On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote: > > > > The term client in OAuth came from the computer science definition of > client-server interaction. > > > > This, I would argue, is exactly why it=E2=80=99s a bad label for somethin= g that=E2=80=99s > distinctly more specific in this context, and I would love to see GNAP > adopt a more specific label for the role that we traditionally called > =E2=80=9Cclient=E2=80=9D in OAuth. > > > > =E2=80=94 Justin > > > > > > The client is getting an access token so it can call a server, > specifically, a resource server (to differentiate it from the authorizati= on > server). > > > > The confusion in my experience usually stems from people working with > software that is acting in multiple roles. IE, the software that is actin= g > as a client in once context, is also acting as an RS in other contexts, o= r > even acting as an AS. The other confusion is that people view clients as > being the software the user is using -- although it may not be acting as = a > client in the oauth context. > > > > > > > > =E1=90=A7 > > > > On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault > wrote: > > Hi, > > > > To me, client has always been a strange word in the context of OAuth, as > it has a meaning well defined both in everyday life (this client is a goo= d > customer) and in computer science (client-server interaction). Thus I > always have to make the mental translation to the OAuth world before any > discussion... And any teaching experience shows that it does make the > concepts hard to grasp for a majority of (clever) people. > > > > As for the RO, previous discussions suggested Resource > Controller (RC) also, which may be a bit more specific than manager. > > > > Fabien > > > > On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: > > Justin and Dick, > > > > [Was: "Revisiting the photo sharing example (a driving use case for the > creation of OAuth)"] > > > > So let us attempt to define new terms: > > *initiating application (IA)*: application by means of which a user > initiates interactions with RS(s) and AS(s) > > In the same way, we should get rid of the term Resource Owner (RO), which > is currently defined as: > > Resource Owner (RO): entity capable of granting access to a protected > resource > > I propose to replace it with Resource Manager (RM): > > *Resource Manager (RM)* : application or user that manages an access > decision function of a Resource Server > > Denis > > > > I agree with Justin. Redefining well used terms will lead to significant > confusion. If we have a different role than what we have had in the past, > then that role should have a name not being used already in OAuth or OIDC= . > > > > Given what we have learned, and my own experience explaining what a Clien= t > is, and is not, improving the definition for Client could prove useful. I > am not suggesting the term be redefined, but clarified. > > > > For example, clarifying that a Client is a role an entity plays in the > protocol, and that the same entity may play other roles at other times, o= r > some other language to help differentiate between "role" and "entity". > > > > /Dick > > =E1=90=A7 > > > > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote: > > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better= fit, but I=E2=80=99m not > really in favor of taking an existing term and applying a completely new > definition to it. In other words, I would sooner stop using =E2=80=9Cclie= nt=E2=80=9D and > come up with a new, more specific and accurate term for the role than to > define =E2=80=9Cclient=E2=80=9D as meaning something completely different= . We did this in > going from OAuth 1 to OAuth 2 already, moving from the even-more-confusin= g > =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, > nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qu= alifies it with > =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Server=E2=80= =9D. > > > > GNAP can do something similar, in my opinion. But what we can=E2=80=99t d= o is > ignore the fact that GNAP is going to be coming up in a world that is > already permeated by OAuth 2 and its terminology. We don=E2=80=99t have = a blank > slate to work with, but neither are we bound to use the same terms and > constructs as before. It=E2=80=99s going to be a delicate balance! > > > > =E2=80=94 Justin > > > > On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: > > > > I think that is fundamentally part of the question: > > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion > > > > If we say that this document assumes OAuth2.0 terminology, then we should > not change the meanings of any definition. If we are saying this supersed= es > or replaces what OAuth 2.0 creates, then we should pick the best word for > the job and ignore conflicting meanings from OAuth 2.0. I have a lot of > first hand experience of industries "ruining words", and attempting to > side-step the problem rather than redefining the word just confuses > everyone as everyone forgets the original meaning as new documents come > out, but the confusion with the use of a non-obvious word continues. > > > > Food for thought. > > - Warren > > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: > > Hi Denis, > > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > > > > Since you replied in parallel, I will make a response similar to the on= e > > I sent to Dick. > > > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in use h= ere. What > > > you describe as RS2, which might in fact be an RS unto itself, is a > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client of= RS1/. What you > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, b= ut it is not at > > > all the same as an OAuth client. I appreciate your mapping of the > > > entities below, but it makes it difficult to hold a discussion if we > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we ca= n define > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new def= initions, > > > but we=E2=80=99ve got a chance to be more precise with how we define = things. > > > > In the ISO context, each document must define its own terminology. The > > boiler plate for RFCs does not mandate a terminology or definitions > section > > but does not prevent it either. The vocabulary is limited and as long a= s > > we clearly define what our terms are meaning, we can re-use a term > already > > used in another RFC. This is also the ISO approach. > > Just because we can do something does not necessarily mean that it is a > good idea to do so. We are clear that we are producing a protocol that i= s > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted Dick = to > use the term "GS" in XAuth, picking a name that was not already used in > OAuth 2.0. > > -Ben > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > 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/ > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > > > *Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/ > . Moneyhub Financial Technology is register= ed > in England & Wales, company registration number 06909772. Moneyhub > Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Build= ing, > Temple Quay, 1 Friary, Bristol, BS1 6EA. * > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000d9d15a05acb11ded Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I agree with=C2=A0that proces= s.=C2=A0

Just as an additional reference (more rel= ated to identity),=C2=A0https://canada-ca.github.io/PCTF-CCP/PCTF.html demonstrates I t= hink the importance of the terminology. In that case, they bring many usefu= l definitions (appendix A). By the way, for them, client is "The inten= ded recipient for a service output. External clients are generally persons = (Canadian citizens, permanent residents, etc.) and businesses (public and p= rivate sector organizations). Internal clients are generally employees and = contractors."

Another example,=C2=A0less obvi= ous: instead of authentication which is a very overloaded term, you end up = with verification and validation for identity and credential (appendix D).= =C2=A0

Then of course one needs to find the ri= ght mix between reinventing the wheel (and the risk=C2=A0of making it hard = to get into) and being specific enough.=C2=A0

Fabi= en

=C2=A0

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.


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


--000000000000d9d15a05acb11ded-- From nobody Wed Aug 12 10:29:59 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 1DC7D3A074B for ; Wed, 12 Aug 2020 10:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 446SmJY3xn9N for ; Wed, 12 Aug 2020 10:29:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34073A073D for ; Wed, 12 Aug 2020 10:29:50 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07CHThm7026384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 13:29:44 -0400 From: Justin Richer Message-Id: <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_CF82D721-BDA9-4CD8-8490-8E3870D63E9A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 12 Aug 2020 13:29:43 -0400 In-Reply-To: Cc: Dick Hardt , Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" To: Fabien Imbault References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Terminology 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: Wed, 12 Aug 2020 17:29:57 -0000 --Apple-Mail=_CF82D721-BDA9-4CD8-8490-8E3870D63E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fabien, There have been a number of additional applications that are getting = discussed. One concrete example is a payments system as written up here: https://github.com/ietf-wg-gnap/general/wiki/Payments = There was also a discussion in the first BoF about a use case where the = interaction with the AS isn=E2=80=99t to gather consent or =E2=80=9Clog = in to the client=E2=80=9D as is typical, but instead to gather = additional information needed for the client to complete the request at = the API. This was framed with an example of collecting credit card = payment details, but I think the concept of =E2=80=9CI need the current = user to come to a web page for a bit=E2=80=9D generalizes to a lot of = different things. It=E2=80=99s still delegation, between the user and = the client, but it=E2=80=99s not a =E2=80=9Cgrant=E2=80=9D unless you = really look at it funny. There=E2=80=99s not a lot being =E2=80=9Cgranted=E2=80=9D here, in my = view of things, and that=E2=80=99s a part of why I am in favor of having = a more precise definition for the term =E2=80=9Cgrant=E2=80=9D instead = of using it as a blanket to cover everything within the protocol.=20 =E2=80=94 Justin > On Aug 12, 2020, at 12:43 PM, Fabien Imbault = wrote: >=20 > Hi Dick,=20 >=20 > Maybe to make that discussion more concrete, what else do you imagine = could be exchanged (beyond resource & idclaims)? A few examples? >=20 > Cheers > Fabien=20 >=20 >=20 >=20 > On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt > wrote: > What is being granted is whatever is being negotiated between the = Grant Server and the Grant Client -> Which fits into the name of the WG, = Grant Negotiation and Authorization Protocol, allows us to have names = that are specific and precise for the roles (Grant Server and Grant = Client rather than Requesting Party), and is usable by an extension that = wants to negotiate some new thing between the two roles.=20 >=20 > I introduced the term "Grant" in XAuth to mean what the client = requested, and what the "server" provided, which included both resource = access and identity claims. You are narrowly defining grant to ONLY mean = "access to something". Sometimes I think you just want to disagree with = me. :) >=20 > I'd be interested in hearing from others! >=20 >=20 >=20 > In the current drafts, that is resource access and identity claims.=20 >=20 > =E1=90=A7 >=20 > On Wed, Aug 12, 2020 at 8:58 AM Justin Richer > wrote: > What is being granted is access to something. This makes sense in = terms of rights bound to an access token, but I would argue it makes = less sense for things returned directly. >=20 > Since you and I also disagree on whether returning things directly is = an important distinction (even though both the XAuth and XYZ proposals = make this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d = want to extend the notion of =E2=80=9Cgrant=E2=80=9D to include anything = and everything in the request and response.=20 >=20 > I am arguing for it being more specific and precise. >=20 > =E2=80=94 Justin >=20 >> On Aug 11, 2020, at 6:08 PM, Dick Hardt > wrote: >>=20 >> A grant is whatever the client is asking from the server. Currently = we have access to resources and identity claims. It could contain = anything else an extension adds that a client may request from a server. >>=20 >> Given the definition of grant that I included, why is grant not the = right term to use for this? >>=20 >>=20 >> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer > wrote: >> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I = said that your definition of it was problematic. Namely, the desire to = lump in claims about the user into the definition of the =E2=80=9Cgrant=E2= =80=9D.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Aug 11, 2020, at 3:49 PM, Dick Hardt > wrote: >>>=20 >>> I agree that orchestrator may be a role in the protocol -- it is not = a role in XYZ or XAuth today. >>>=20 >>> Justin: would you explain why you think the term "grant" is = problematic? It is in the WG name! >>>=20 >>> The client is receiving more than access to resources from the GS, = it is also receiving claims, so "client of the resource" is too = limiting. >>>=20 >>> Reading the definition of grant[1], it fits as a verb of what the GS = is doing, and fits as a noun of what the GS provides to the client. >>>=20 >>> A Grant Server is an Authorization Server in OAuth, and an OpenID = Provider in OpenID Connect. >>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID = Connect. >>>=20 >>> Having new terms (GS and GC) in GNAP, separating the roles from = OAuth and OpenID Connect. >>> It is straightforward to know what a GC and GS do when you = understand that a grant is a combination of resource access (from OAuth) = and claims (from OpenID Connect). >>>=20 >>> /Dick >>>=20 >>> [1] https://www.dictionary.com/browse/grant = >>> verb (used with object) >>> to bestow or confer, especially by a formal act: >>> to grant a charter. >>> to give or accord: >>> to grant permission. >>> to agree or accede to: >>> to grant a request. >>> to admit or concede; accept for the sake of argument: >>> I grant that point. >>> SEE MORE >>> noun >>> something granted, as a privilege or right, a sum of money, or a = tract of land: >>> Several major foundations made large grants to fund the research = project. >>> the act of granting. >>>=20 >>>=20 >>> [1]=20 >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer > wrote: >>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what = the classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but = the term =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser = agent=E2=80=9D concept that=E2=80=99s been brought up here before, so = I=E2=80=99m inclined to believe it can be a separate role from the = client. >>>=20 >>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing = as it is not a =E2=80=9Cclient of the grant=E2=80=9D but rather a = =E2=80=9Cclient of the resource=E2=80=9D. >>>=20 >>> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt > wrote: >>>>=20 >>>> I echo Mike's comments on preserving names when possible. The shift = from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to many. >>>>=20 >>>> I also echo Tom's comments about separating Entities from Roles. >>>>=20 >>>> Orchestration[1] in my opinion is not what the "client" is doing. >>>>=20 >>>> Below is a stab at separating the entities and the roles >>>>=20 >>>> /Dick >>>>=20 >>>> Tl;dr:=20 >>>> - Client -> Grant Client >>>> - added Relying Party, Claims Issuer, and Grant Server Operator as = entities >>>>=20 >>>> Roles - parties to the protocol >>>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>>=20 >>>> Entities - parties to a Trust Framework >>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server = Operator (GSO), Resource Owner (RO) >>>>=20 >>>> Grant - may contain claims and/or access to resources >>>>=20 >>>> #Protocol Roles >>>>=20 >>>> Grant Client (GC) >>>> - used by User >>>> - operated / provided by RP >>>> - requests Grants from the GS >>>> - access resources at an RS >>>> - consumes Claims >>>>=20 >>>> Grant Server (GS) >>>> - operated by GSO >>>> - may interact with the User=20 >>>> - may interact with the RO >>>> - accepts grant requests from GCs >>>> - issues grants to GCs >>>> - may issue claims >>>>=20 >>>> Resource Server (RS) >>>> - manages access to resources for the RO >>>> - provides access to resources for the GC >>>> - accepts access granted by the GS >>>>=20 >>>> #Legal Entities >>>>=20 >>>> User >>>> - uses Grant Client >>>> - may interact with the Grant Server >>>> - may also be a RO >>>> - trusts RP, Issuer, GSO >>>>=20 >>>> Relying Party (RP) >>>> - provides Grant Client to the User. >>>> - may trust Issuers, GSOs, and ROs >>>>=20 >>>> Claims Issuer (Issuer) >>>> - issues claims to RP >>>> - may use GS or RS to issue claims >>>>=20 >>>> Grant Server Operator (GSO) >>>> - operates the GS >>>> - trusted by User, RP, and RO >>>> - may also be an Issuer >>>>=20 >>>> Resource Owner (RO) >>>> - owns resources at the RS >>>> - trusts GSO to control access to the resources >>>> - may be same entity as the User >>>> - may also be an Issuer >>>>=20 >>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) = >>>>=20 >>>> Orchestration (computing) >>>> =46rom Wikipedia, the free encyclopedia >>>> Jump to navigation >>>> = Jump to = search >>>> = In = system administration = , orchestration is = the automated configuration = , coordination, = and management of computer systems and software = .[1] = >>>> A number of tools exist = for = automation of server configuration and management, including Ansible = , Puppet = , Salt = , Terraform = ,[2] = = and AWS CloudFormation = .[3] = >>>> Usage[edit = ] >>>> Orchestration is often discussed in the context of service-oriented = architecture = , = virtualization , = provisioning , converged = infrastructure = and dynamic datacenter = topics. Orchestration in this sense is about aligning the business = request with the applications, data, and infrastructure.[4] = >>>> In the context of cloud computing = , the main difference = between workflow automation = and orchestration is = that workflows are processed and completed as processes within a single = domain for automation purposes, whereas orchestration includes a = workflow and provides a directed action towards larger goals and = objectives.[1] = >>>> In this context, and with the overall aim to achieve specific goals = and objectives (described through quality of service = parameters), for = example, meet application performance goals using minimized cost[5] = and maximize application performance within budget = constraints.[6] = >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones = > = wrote: >>>> One of the things that people hated about OAuth was it invented new = terminology that wasn=E2=80=99t in common use. But for better or for = worse, the terms Client, Authorization Server, and Protected Resource = are now widely understood. >>>>=20 >>>> =20 >>>>=20 >>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even = more novel terms, when existing terms will fit the bill. Client = wasn=E2=80=99t a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D = to the vocabulary menagerie would definitely make things worse. >>>>=20 >>>> =20 >>>>=20 >>>> -- Mike >>>>=20 >>>> =20 >>>>=20 >>>> From: TXAuth > On Behalf Of Tom Jones >>>> Sent: Tuesday, August 11, 2020 8:44 AM >>>> To: Dave Tonge > >>>> Cc: Francis Pouatcha >; = Justin Richer >; Dick Hardt = >; Benjamin Kaduk = >; Fabien Imbault = >; Denis = >; txauth@ietf.org = >>>> Subject: Re: [GNAP] Terminology >>>>=20 >>>> =20 >>>>=20 >>>> the term "orchestator" does not match any use case i have. >>>>=20 >>>> Let's be clear that there are four entities to a single transaction = in the real world sense of things. (and others that support the = transaction.) >>>>=20 >>>> Then we can focus on the end point roles. I will focus on the data = privacy issues, API's have the same parties with different terminology. >>>>=20 >>>> 1. the subject of the data to be transferred. >>>>=20 >>>> 2. the user of a grant from the subject to act as delegate. (see = https://wiki.idesg.org/wiki/index.php/Delegation = for how to enable the = user) >>>>=20 >>>> 3. the site that has a repository of user data with legal = obligations to protect that data (the GDPR) (role resource server.) >>>>=20 >>>> 4 the site that wants either access to the data, or some privacy = preserving statement about the existence and content of the data. (role = of client, vendor, PISP, etc.) >>>>=20 >>>> 5. some sorts of facilitator sites for allowing access (roles like = authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been = left out of OAUTH for good reason. >>>>=20 >>>> =20 >>>>=20 >>>> This is a note supporting the separation of roles from legal = entities. BTW, I firmly believe that the legal entity also needs to be = ID'd by the transaction. >>>>=20 >>>> Peace ..tom >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge > wrote: >>>>=20 >>>> Hi all >>>>=20 >>>> =20 >>>>=20 >>>> I agree that "client" can be confusing. I would be in support of = alternative terminology. >>>>=20 >>>> We can always have some wording that explains that an = "Orchestrator" in GNAP plays a similar role to "Client" in OAuth. >>>>=20 >>>> =20 >>>>=20 >>>> Dave >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault = > wrote: >>>>=20 >>>> Hi Francis, >>>>=20 >>>> =20 >>>>=20 >>>> I like your proposal, seems much more intuitive.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> =20 >>>>=20 >>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha = > a =C3=A9crit : >>>>=20 >>>> Hello Denis, Justin, Dick, Fabien, >>>>=20 >>>> =20 >>>>=20 >>>> In this post = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ) i suggested we use the word "Orchestrator" to designate the piece of = software that orchestrate interaction between "Requestor" (a.k.a. User), = AS and RS to obtain the protected resource.=20 >>>>=20 >>>> =20 >>>>=20 >>>> We are turning around the same topic. As soon as we go beyond the = original oAuth protocol, the word 'Client' becomes confusing. >>>>=20 >>>> =20 >>>>=20 >>>> In the same response, I suggest we talk about "roles" and not = "entities". >>>>=20 >>>> =20 >>>>=20 >>>> Best regards. >>>>=20 >>>> /Francis >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt > wrote: >>>>=20 >>>> I still think that client was the right name in OAuth 2, as the = client wanted to do a client-server interaction, so the client used = OAuth 2 to get an access token to interact with the "server". >>>>=20 >>>> =20 >>>>=20 >>>> I do agree that it is not the best term in GNAP. Primarily because = GNAP is a combination of the client from OAuth 2, and the relying party = from OIDC.=20 >>>>=20 >>>> =20 >>>>=20 >>>> /Dick >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer > wrote: >>>>=20 >>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt > wrote: >>>>=20 >>>> =20 >>>>=20 >>>> The term client in OAuth came from the computer science definition = of client-server interaction. >>>>=20 >>>> =20 >>>>=20 >>>> This, I would argue, is exactly why it=E2=80=99s a bad label for = something that=E2=80=99s distinctly more specific in this context, and I = would love to see GNAP adopt a more specific label for the role that we = traditionally called =E2=80=9Cclient=E2=80=9D in OAuth. >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> The client is getting an access token so it can call a server, = specifically, a resource server (to differentiate it from the = authorization server). >>>>=20 >>>> =20 >>>>=20 >>>> The confusion in my experience usually stems from people working = with software that is acting in multiple roles. IE, the software that is = acting as a client in once context, is also acting as an RS in other = contexts, or even acting as an AS. The other confusion is that people = view clients as being the software the user is using -- although it may = not be acting as a client in the oauth context. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault = > wrote: >>>>=20 >>>> Hi,=20 >>>>=20 >>>> =20 >>>>=20 >>>> To me, client has always been a strange word in the context of = OAuth, as it has a meaning well defined both in everyday life (this = client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the = OAuth world before any discussion... And any teaching experience shows = that it does make the concepts hard to grasp for a majority of (clever) = people. >>>>=20 >>>> =20 >>>>=20 >>>> As for the RO, previous discussions suggested Resource Controller = (RC) also, which may be a bit more specific than manager.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Fabien=20 >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Aug 6, 2020 at 1:00 PM Denis > wrote: >>>>=20 >>>> Justin and Dick, >>>>=20 >>>> =20 >>>>=20 >>>> [Was: "Revisiting the photo sharing example (a driving use case = for the creation of OAuth)"] >>>>=20 >>>> =20 >>>>=20 >>>> So let us attempt to define new terms: >>>>=20 >>>> initiating application (IA): application by means of which a user = initiates interactions with RS(s) and AS(s) >>>>=20 >>>> In the same way, we should get rid of the term Resource Owner (RO), = which is currently defined as: >>>>=20 >>>> Resource Owner (RO): entity capable of granting access to a = protected resource >>>>=20 >>>> I propose to replace it with Resource Manager (RM): >>>>=20 >>>> Resource Manager (RM) : application or user that manages an access = decision function of a Resource Server >>>>=20 >>>> Denis >>>>=20 >>>> =20 >>>>=20 >>>> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>>>=20 >>>> =20 >>>>=20 >>>> Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>>>=20 >>>> =20 >>>>=20 >>>> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>>>=20 >>>> =20 >>>>=20 >>>> /Dick >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> =20 >>>>=20 >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >>>>=20 >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>=20 >>>> =20 >>>>=20 >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>>>=20 >>>> =20 >>>>=20 >>>> I think that is fundamentally part of the question: >>>>=20 >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>> confusion >>>>=20 >>>> =20 >>>>=20 >>>> If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >>>>=20 >>>> =20 >>>>=20 >>>> Food for thought. >>>>=20 >>>> - Warren >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Warren Parad >>>>=20 >>>> Founder, CTO >>>>=20 >>>> Secure your user data and complete your authorization architecture. = Implement Authress . >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>>>=20 >>>> Hi Denis, >>>>=20 >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> >=20 >>>> > Since you replied in parallel, I will make a response similar to = the one=20 >>>> > I sent to Dick. >>>> >=20 >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in = use here. What=20 >>>> > > you describe as RS2, which might in fact be an RS unto itself, = is a=20 >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >>>> > > all the same as an OAuth client. I appreciate your mapping of = the=20 >>>> > > entities below, but it makes it difficult to hold a discussion = if we=20 >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can define=20 >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,=20 >>>> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >>>> >=20 >>>> > In the ISO context, each document must define its own = terminology. The=20 >>>> > boiler plate for RFCs does not mandate a terminology or = definitions section >>>> > but does not prevent it either. The vocabulary is limited and as = long as=20 >>>> > we clearly define what our terms are meaning, we can re-use a = term already >>>> > used in another RFC. This is also the ISO approach. >>>>=20 >>>> Just because we can do something does not necessarily mean that it = is a >>>> good idea to do so. We are clear that we are producing a protocol = that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted = Dick to >>>> use the term "GS" in XAuth, picking a name that was not already = used in >>>> OAuth 2.0. >>>>=20 >>>> -Ben >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> Francis Pouatcha >>>>=20 >>>> Co-Founder and Technical Lead >>>>=20 >>>> adorsys GmbH & Co. KG >>>>=20 >>>> https://adorsys-platform.de/solutions/ = >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>>>=20 >>>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>>=20 >>>>=20 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 --Apple-Mail=_CF82D721-BDA9-4CD8-8490-8E3870D63E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Fabien,

There have been a number of additional applications that are = getting discussed. One concrete example is a payments system as written = up here:

https://github.com/ietf-wg-gnap/general/wiki/Payments
=

There was also a = discussion in the first BoF about a use case where the interaction with = the AS isn=E2=80=99t to gather consent or =E2=80=9Clog in to the = client=E2=80=9D as is typical, but instead to gather additional = information needed for the client to complete the request at the API. = This was framed with an example of collecting credit card payment = details, but I think the concept of =E2=80=9CI need the current user to = come to a web page for a bit=E2=80=9D generalizes to a lot of different = things. It=E2=80=99s still delegation, between the user and the client, = but it=E2=80=99s not a =E2=80=9Cgrant=E2=80=9D unless you really look at = it funny.

There=E2=80=99s not a lot being =E2=80=9Cgranted=E2=80=9D = here, in my view of things, and that=E2=80=99s a part of why I am in = favor of having a more precise definition for the term =E2=80=9Cgrant=E2=80= =9D instead of using it as a blanket to cover everything within the = protocol. 

 =E2=80=94 Justin

On Aug = 12, 2020, at 12:43 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Dick, 

Maybe to make that discussion more = concrete, what else do you imagine could be exchanged (beyond resource = & idclaims)? A few examples?

Cheers
Fabien 



On Wed, Aug = 12, 2020 at 6:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
What is = being granted is whatever is being negotiated between the Grant Server = and the Grant Client -> Which fits into the name of the WG, Grant = Negotiation and Authorization Protocol, allows us to have names that are = specific and precise for the roles (Grant Server and Grant Client rather = than Requesting Party), and is usable by an extension that wants to = negotiate some new thing between the two roles. 

I introduced the term "Grant" in XAuth = to mean what the client requested, and what the "server" provided, which = included both resource access and identity claims. You are narrowly = defining grant to ONLY mean "access to something". Sometimes I think you = just want to disagree with me. :)

I'd be interested in hearing from = others!



In the current drafts, = that is resource access and identity claims. 

3D""=E1=90=A7

On Wed, Aug = 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> wrote:
What is being granted = is access to something. This makes sense in terms of rights bound to an = access token, but I would argue it makes less sense for things returned = directly.

Since you = and I also disagree on whether returning things directly is an important = distinction (even though both the XAuth and XYZ proposals make this = distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d want to = extend the notion of =E2=80=9Cgrant=E2=80=9D to include anything and = everything in the request and response. 

I am arguing for it being more specific = and precise.

 =E2=80=94 Justin

On Aug = 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

A grant is whatever the client is = asking from the server. Currently we have access to resources and = identity claims. It could contain anything else an extension adds that a = client may request from a server.

Given the definition of grant that I included, why is grant = not the right term to use for this?


On Tue, Aug 11, 2020 at 1:35 PM Justin = Richer <jricher@mit.edu> wrote:
I did not say = the term =E2=80=9Cgrant=E2=80=9D was problematic, I said that your = definition of it was problematic. Namely, the desire to lump in claims = about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. 
 =E2=80=94 = Justin

On Aug 11, 2020, at 3:49 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that orchestrator may be = a role in the protocol -- it is not a role in XYZ or XAuth today.

Justin: would you = explain why you think the term "grant" is problematic? It is in the WG = name!

The = client is receiving more than access to resources from the GS, it = is also receiving claims, so "client of the resource" is too = limiting.

Reading the definition of grant[1], it fits as a verb of what = the GS is doing, and fits as a noun of what the GS provides to the = client.

A = Grant Server is an Authorization Server in OAuth, and an OpenID Provider = in OpenID Connect.
The Grant Client is a Client in = OAuth, and a Relying Party in OpenID Connect.

Having new terms (GS and GC) in GNAP, = separating the roles from OAuth and OpenID Connect.
It is straightforward to know what a GC and GS do when = you understand that a grant is a combination of resource access = (from OAuth) and claims (from OpenID Connect).

/Dick

[1] https://www.dictionary.com/browse/grant

verb (used with = object)

to bestow or confer, especially by a formal act:to grant a = charter.
to give or accord:to grant = permission.
to agree or accede to:to grant a = request.
to admit or concede; accept for the sake of argument:I grant that = point.

noun

something granted, as a privilege or right, a sum of money, = or a tract of land:Several major foundations made large = grants to fund the research project.
the act of granting.


[1] 



On Tue, Aug = 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that = =E2=80=9Corchestration=E2=80=9D is separate from what the classical = =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term = =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D = concept that=E2=80=99s been brought up here before, so I=E2=80=99m = inclined to believe it can be a separate role from the client.

I personally think that = =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient= of the grant=E2=80=9D but rather a =E2=80=9Cclient of the = resource=E2=80=9D.

I also think it=E2=80=99s problematic to lump in user claims = with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to muddle = everything. 

 =E2=80=94 Justin

On Aug = 11, 2020, at 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I echo Mike's comments on = preserving names when possible. The shift from "consumer" in OAuth 1 to = "client" in OAuth 2 was confusing to many.

I also echo Tom's = comments about separating Entities from Roles.

Orchestration[1] in my opinion is not = what the "client" is doing.

Below is a stab at separating the entities and the = roles

/Dick

Tl;dr: 
- = Client -> Grant Client
- added Relying = Party, Claims Issuer, and Grant Server Operator as entities

Roles - parties to the protocol
Grant = Client (GC), Grant Server (GS), Resource Server (RS)

Entities - parties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Issuer), Grant = Server Operator (GSO), Resource Owner (RO)

Grant - may contain claims and/or = access to resources

#Protocol Roles

Grant Client = (GC)
- used by User
- operated = / provided by RP
- requests Grants from the = GS
- access resources at an RS
-= consumes Claims

Grant Server (GS)
- = operated by GSO
- may interact with the = User 
- may interact with the RO
- accepts grant requests from GCs
- = issues grants to GCs
- may issue claims

Resource = Server (RS)
- manages access to resources for = the RO
- provides access to resources for the = GC
- accepts access granted by the GS

#Legal = Entities

User
- uses Grant Client
- may interact with the Grant Server
- = may also be a RO
- trusts RP, Issuer, GSO

Relying = Party (RP)
- provides Grant Client to the User. =
- may trust Issuers, GSOs, and ROs

Claims = Issuer (Issuer)
- issues claims to RP
- may use GS or RS to issue claims

Grant Server Operator = (GSO)
- operates the GS
- = trusted by User, RP, and RO
- may also be an = Issuer

Resource Owner (RO)
- = owns resources at the RS
- trusts GSO to control = access to the resources
- may be same entity as the = User
- may also be an = Issuer

[1] https://en.wikipedia.org/wiki/Orchestration_(computing)

Orchestration (computing)

=46rom Wikipedia, the free = encyclopedia
Jump to navigationJump to search
In system administration, orchestration is the automated configuration, coordination, and = management of computer systems and software.[1]
A number of tools exist for = automation of server configuration and management, including Ansible, Puppet, Salt, Terraform,[2] and AWS CloudFormation.[3]

Usage[edit]

Orchestration is often discussed in the context of service-oriented architecture, virtualization, provisioning, converged infrastructure and = dynamic datacenter topics. Orchestration = in this sense is about aligning the business request with the = applications, data, and infrastructure.[4]
In the context of cloud computing, the main difference = between workflow automation and = orchestration is that workflows are processed and completed as processes = within a single domain for automation purposes, whereas orchestration = includes a workflow and provides a directed action towards larger goals = and objectives.[1]
In this context, and with the overall aim to achieve = specific goals and objectives (described through quality of service parameters), = for example, meet application performance goals using minimized cost[5] and maximize application = performance within budget constraints.[6]








On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

One of the things that people hated about OAuth was it = invented new terminology that wasn=E2=80=99t in common use.  But = for better or for worse, the terms Client, Authorization Server, and = Protected Resource are now widely understood.

 

Let=E2=80= =99s not make people similarly hate GNAP by inventing even more novel = terms, when existing terms will fit the bill.  Client wasn=E2=80=99t = a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the = vocabulary menagerie would definitely make things worse.

 

          &nb= sp;   =             &n= bsp;           &nbs= p;            =     -- Mike

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

 

the term "orchestator" does not = match any use case i have.

Let's be clear that there are = four entities to a single transaction in the real world sense of things. = (and others that support the  transaction.)

Then we can focus on the end = point roles. I will focus on the data privacy issues, API's have the = same parties with different terminology.

1. the subject of the data to be = transferred.

2. the user of a grant from the = subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how = to enable the user)

3. the site that has a repository = of user data with legal obligations to protect that data (the GDPR) = (role resource server.)

4 the site that wants either = access to the data, or some privacy preserving statement about the = existence and content of the data. (role of client, vendor, PISP, = etc.)

5. some sorts of facilitator = sites for allowing access (roles like authenticator, idp, verifier, csp, = RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

 

This is a note supporting the = separation of roles from legal entities.  BTW, I firmly believe = that the legal entity also needs to be ID'd by the transaction.

Peace ..tom

 

 

On Tue, Aug 11, 2020 at 1:42 AM = Dave Tonge <dave.tonge@moneyhub.com> wrote:

Hi = all

 

I = agree that "client" can be confusing. I would be in support of = alternative terminology.

We = can always have some wording that explains that an "Orchestrator" in = GNAP plays a similar role to "Client" in OAuth.

 

Dave

 

On Tue, 11 Aug 2020 at 07:52, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Francis,

 

I like your proposal, seems much = more intuitive. 

 

Fabien 

 

Le mar. 11 ao=C3=BBt 2020 =C3=A0 = 04:17, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit :

Hello Denis, Justin, Dick, = Fabien,

 

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between = "Requestor" (a.k.a. User), AS and RS to obtain the protected = resource. 

 

We are turning around the same = topic. As soon as we go beyond the original oAuth protocol, the = word 'Client' becomes confusing.

 

In the same response, I = suggest we talk about "roles" and not "entities".

 

Best regards.

/Francis

 

On Thu, Aug 6, 2020 at 6:36 PM = Dick Hardt <dick.hardt@gmail.com> wrote:

I still think that client was the = right name in OAuth 2, as the client wanted to do a client-server = interaction, so the client used OAuth 2 to get an access token to = interact with the "server".

 

I do agree that it is not the = best term in GNAP. Primarily because GNAP is a combination of the client = from OAuth 2, and the relying party from OIDC. 

 

/Dick

=E1=90=A7

 

On Thu, Aug 6, 2020 at 12:50 PM = Justin Richer <jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

 

The term client in OAuth came = from the computer science definition of client-server interaction.

 

This, I would argue, is exactly = why it=E2=80=99s a bad label for something that=E2=80=99s distinctly = more specific in this context, and I would love to see GNAP adopt a more = specific label for the role that we traditionally called =E2=80=9Cclient=E2= =80=9D in OAuth.

 

 =E2=80=94 Justin



 

The client is getting an access = token so it can call a server, specifically, a resource server (to = differentiate it from the authorization server).

 

The confusion in my experience = usually stems from people working with software that is acting = in multiple roles. IE, the software that is acting as a client = in once context, is also acting as an RS in other contexts, or even = acting as an AS. The other confusion is that people view clients as being the = software the user is using -- although it may not be acting as a client = in the oauth context.

 

 

 

=E1=90=A7

 

On Thu, Aug 6, 2020 at 4:49 AM = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

 

To me, client has always been a = strange word in the context of OAuth, as it has a meaning well defined = both in everyday life (this client is a good customer) and in computer = science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And = any teaching experience shows that it does make the concepts hard to = grasp for a majority of (clever) people.

 

As for the RO, previous = discussions suggested Resource Controller (RC) also, which may = be a bit more specific than manager. 

 

Fabien 

 

On Thu, Aug 6, 2020 at 1:00 PM = Denis <denis.ietf@free.fr> wrote:

Justin and = Dick,

 

[Was:  = "Revisiting the photo sharing example (a driving use case for the = creation of OAuth)"]

 

So let us attempt to = define new terms:

initiating application = (IA): = application by means of which a user initiates interactions with RS(s) = and AS(s)

In the same way, we = should get rid of the term Resource Owner (RO), which is currently = defined as:

Resource Owner (RO): = entity capable of granting access to a protected resource

I propose to replace = it with Resource Manager (RM):

Resource Manager = (RM) = : application or user that manages an access decision function of a = Resource Server

Denis

 

I agree with Justin. Redefining = well used terms will lead to significant confusion. If we have a = different role than what we have had in the past, then that role = should have a name not being used already in OAuth or OIDC.

 

Given what we have learned, and = my own experience explaining what a Client is, and is not, improving the = definition for Client could prove useful. I am not suggesting the term = be redefined, but clarified. 

=

 

For example, clarifying that a = Client is a role an entity plays in the protocol, and that the same = entity may play other roles at other times, or some other language to = help differentiate between "role" and "entity".

 

/Dick

=E1=90=A7

 

On Wed, Aug 5, 2020 at 8:20 AM = Justin Richer <jricher@mit.edu> wrote:

I=E2=80=99m in favor of coming up = with a new term that=E2=80=99s a better fit, but I=E2=80=99m not really = in favor of taking an existing term and applying a completely new = definition to it. In other words, I would sooner stop using =E2=80=9Cclien= t=E2=80=9D and come up with a new, more specific and accurate term for the role than to define = =E2=80=9Cclient=E2=80=9D as meaning something completely different. We = did this in going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizat= ion Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

 

GNAP can do something similar, in = my opinion. But what we can=E2=80=99t do is ignore the fact that GNAP is = going to be coming up in a world that is already permeated  by = OAuth 2 and its terminology. We don=E2=80=99t have a blank slate to work = with, but neither are we bound to use the same terms and constructs as before. = It=E2=80=99s going to be a delicate balance!

 

 =E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, = Warren Parad <wparad@rhosys.ch> wrote:

 

I think that is fundamentally = part of the question:

We are clear that we are producing a protocol that = is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

 

If we say that this document = assumes OAuth2.0 terminology, then we should not change the meanings of = any definition. If we are saying this supersedes or replaces what OAuth = 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand = experience of industries "ruining words", and attempting to side-step = the problem rather than redefining the word just confuses everyone as = everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious = word continues.

 

Food for thought.

- Warren

Warren = Parad

Founder, = CTO

Secure your user data and complete your authorization = architecture. Implement Authress.

 

 

On Tue, Aug 4, 2020 at 8:53 PM = Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the = OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

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

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

 

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

 

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

 

--
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/

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

 

 

Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number 06909772. = Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject = to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are = made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's = business. Any opinions expressed in this email (or in any attachments) = are those of the author and do not necessarily represent the opinions of = Moneyhub Financial Technology Limited or of any other group company.


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





= --Apple-Mail=_CF82D721-BDA9-4CD8-8490-8E3870D63E9A-- From nobody Wed Aug 12 10:39:52 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 029363A0860 for ; Wed, 12 Aug 2020 10:39:51 -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 xN9-KNJ0keVD for ; Wed, 12 Aug 2020 10:39:49 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 BDF523A07EA for ; Wed, 12 Aug 2020 10:39:48 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id p14so2510999wmg.1 for ; Wed, 12 Aug 2020 10:39:48 -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=zfNA8BUH9euMxwjOldVGJWs1nMHcvYc5TzkpeoLzq1s=; b=DtHKI17vQPlKYIw3fK7E7n+D+RqkjAVnDJbsEYvnYaSfL0cpzRUOYcTZEDukCKf9P/ isBpAsf608edYCZK92w1peKceyX/9ZA9vv1y/FHWjSlxWf6b0gEfSyCznJ72ktAe0G2p kkcaezmlx9f3oZIopUQl5tilCGd2m4NiRJJU4= 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=zfNA8BUH9euMxwjOldVGJWs1nMHcvYc5TzkpeoLzq1s=; b=mSjk3B+AZbElHVaj0rI9mgpMuaDKez4tPezYt4eYl5sih4ZEfB3VHL8n6QawclBYzl zvLzr+z0vlfruZuAy3uto+QnJqX3u9cd4jqzDYLOE4+fjKGEPniyWgeV4BWcvhSyhwkd kLexTbgGm7ePQvhq6J3x956RDtaso+lKkkWm8GgrhALouYeoWMlKSVshtg9vGQUd4fAn WCmOBappUu0zsYYmlEd6txG7t052q7c+JDgxNGMLQ1ZLPtUlBAlsiPE6ut9pUHEoonaj OdWfkBJ77kmn/LOgaoWVO8rU+PMDWQq80mHCnKROA4SyBCly6hq+MX7312a+qv9iEJjD oHBw== X-Gm-Message-State: AOAM532tcuXkPdn5Ta7D6JGdAwXa6ieyreMRnk9yrKz/8ZX1UZY/AViH 8PEBofzaA98k+JrlsNaugDEwX84GJTLGqT350Cf8YA== X-Google-Smtp-Source: ABdhPJwYBdwY6H9ihw0tdKDz0+csYhp4TRUfynF+o9nXpfRB5a9kUK7x/TxQSNisFotKv3cXNQXXfia01CZ+XGyVLuY= X-Received: by 2002:a1c:770c:: with SMTP id t12mr751821wmi.65.1597253987119; Wed, 12 Aug 2020 10:39:47 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> In-Reply-To: From: Francis Pouatcha Date: Wed, 12 Aug 2020 13:39:36 -0400 Message-ID: To: Dick Hardt Cc: Denis , Justin Richer , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000084ce3705acb1ac64" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 12 Aug 2020 17:39:51 -0000 --00000000000084ce3705acb1ac64 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 12, 2020 at 12:55 PM Dick Hardt wrote: > comments inline ... > > On Wed, Aug 12, 2020 at 7:14 AM Denis wrote: > >> Hi Dick, >> >> Hi Francis, responses inline ... >> >> On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha wrote: >> >>> Hello Dick, >>> >>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt wrote: >>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the protocol in how I am defining >>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>> >>> "Requestor" is the role (*was* User). So the UML participant refers to >>> the role "Requestor" >>> >> >> I still don't understand what is happening in (1) and (7) >> >> > Would you provide more explanation? > Step (1) is the initial service request "RegisterStudent" sent by the university staff to the University registration application. Step (7) is the response to step (1), the notification of the university staff that the registration was successful. Do you need more? -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --00000000000084ce3705acb1ac64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 12, 2020 at 12:55 PM Dick= Hardt <dick.hardt@gmail.com= > wrote:
comments inline ...=C2=A0

On Wed, Aug 12, 2020= at 7:14 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hi Dick,

=20
Hi Francis, responses inline ...=C2=A0

On Tue, Aug 11, 2020 at 3:3= 7 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). S= o the UML participant refers=C2=A0to the role "Requestor&q= uot;

I still don't understand what is happening in (1) and (7= )

Woul= d you provide more explanation?
Step (1) is the initial service request "RegisterStud= ent" sent by the=C2=A0university staff to the University registration = application.
Step (7= ) is the response to step (1), the notification of the university staff tha= t the registration was successful.=C2=A0

Do= you need more?
--
Francis Pouatcha
Co-Founder and Technical Lea= d
adorsys GmbH & Co. KG
--00000000000084ce3705acb1ac64-- From nobody Thu Aug 13 02:49:53 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 D76813A0AC7 for ; Thu, 13 Aug 2020 02:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 OX90cDtrnyHr for ; Thu, 13 Aug 2020 02:49:46 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 F36C23A0AD9 for ; Thu, 13 Aug 2020 02:49:45 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id u126so6569036iod.12 for ; Thu, 13 Aug 2020 02:49:45 -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=EdL1gDqF1rCajRYHGhQahXB/+4gw0kfH8HT5zZJalFI=; b=ijC/BqFRCxJDIrnHEYLJJvbxYcYSpT5AGg6/zevjZUYI8WrhtQpYZniG+HMEBSgtjr wWoh3RwimRBb1De+UCJ8e+R9HsrP6foLq1DcPACfzxf7VRfSXBGlzaap1ewuj6wqfdcC WA7n/Sp8p5TAKSjBrM9lI9Kp2x9xJ6bko+yTyTw7YLEpzek0g4N+6iqPgrzXKLrMV1+U a64b6956jKXaQfk57grj2PkcecPUXl33SUwdSVwsPjPB20+rUIt7fCFufatSM5I5665m mYrYVtpN/ST2mdTZ3776k7zwJYG18cCMaOEcqCG9gMNd5pO/ftkcVYyctI6heoD7Glvn 6wzA== 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=EdL1gDqF1rCajRYHGhQahXB/+4gw0kfH8HT5zZJalFI=; b=QWan8q1eH0aauMzecSqfJAWZh3HuKNDSPDIoYDQJkKy4vG4RgkzPfscR9xWP/xMKmx aIlrdjaixas+YaUJ1DMFb6ONckQxPZ12VhWRj5Um5NvDuAuOHZ05d54iyA/3t1n0AiCf DNvGhtmgfxoau9+jrZ4kjcDnV2iPIViwj3zjcN3qptEQWtPKj0DrATitmAcTXEBL74jQ gc2UMfxsVSiAMWAb+ASc/4XmXK3DNK8kcIKYYjaZKE1u/gL+zI/TfwR8fmIMyF2X9Wkc BEj74UcyqZnWsJMWAOwPCkPfuErQiJmw/DlR+PbAg+sClv5hlZcp1xlV1fe1FaKhsJdY JY4g== X-Gm-Message-State: AOAM533yHisirGLNCvCgQ1R82Pn4CYi7GzU2awjFIVwejaRO/qaMSuBm 7QpuMd2YFPzqxfa7pdtTNMMqjnkKmdiPA6WDPpI= X-Google-Smtp-Source: ABdhPJwUnEu7wPi3bZYJsA3zIJ9jHVJ+ZfydHTWpjRNysEfuxSmqVvXYRuFungaY8ugq4KafiQPFsAW/ag5xC3l+iBk= X-Received: by 2002:a6b:e70d:: with SMTP id b13mr3995011ioh.141.1597312184831; Thu, 13 Aug 2020 02:49:44 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> In-Reply-To: <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> From: Fabien Imbault Date: Thu, 13 Aug 2020 11:49:32 +0200 Message-ID: To: Justin Richer Cc: Dick Hardt , Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005f556905acbf3945" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 13 Aug 2020 09:49:52 -0000 --0000000000005f556905acbf3945 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot. Terminology is hard and so I'm thankful for anyone that submits a definition or provides constructive criticism ;-) I think we shouldn't try to be perfect from the start (and probably never will be). What matters is that we gradually try to clarify what we mean within our context, and as much as possible, but be careful not use a usual term in a completely different way (changes to well accepted terms should be limited to the extreme). In that sense, starting from the dictionary is a good idea, as per Dick's proposal. Two of the verb definitions fit quite well to our objectives, without change. to give or accord -> fits well with the token generation (accord) and dispatch (give) to agree or accede to -> fits well with the consent phase (the other 2 definitions are irrelevant to our scope) The original definition of grant (as a noun) is already enabling some extensibility ("*something* granted, as a privilege or right, a sum of money, or a tract of land"). That could come handy! - privilege: pretty much what we expect from an identity claim - right: what we expect from an access token - sum of money:similar to the https://github.com/ietf-wg-gnap/general/wiki/Payments use case. - tract of land: a bit more alien ( https://www.lawinsider.com/dictionary/tract-of-land), but maybe related to the "Signing contracts" example of the previous use case? Unsure about this one, I tentatively propose something in the definition that comes afterwards. Probably a rewording is necessary, but it seems to cover a large part of what we are looking for. So here's what I would propose as a starting point: *GRANT (verb)* *to give or accordExample: to grant permission.to agree or accede toExample: to grant consent.* *Note: in the GNAP protocol, the act of granting generally involves automated processes (by computers) and human interactions through a web browser. * *GRANT (noun)* *something granted, as a privilege or right, a sum of money or as the outcome of an obligation or a promise* *Example 1: digital access token to a protected resource.* *Example 2: privilege derived from an identity claim.* *Example 3: a sum of money granted by the customer to a service provider, as the result of a payment flow initiated at the retail store or via ecommerce.* *Example 4: access right to open and drive a car, from a car sharing company (by contract) or from a relative (by promise). * *Note: in the GNAP protocol, a grant is negotiated between a and a grant server and usually involves the processing and exchange of identity claims and/or access tokens.* =3D term to be changed Any feedback welcome. Le mer. 12 ao=C3=BBt 2020 =C3=A0 19:29, Justin Richer a = =C3=A9crit : > Fabien, > > There have been a number of additional applications that are getting > discussed. One concrete example is a payments system as written up here: > > https://github.com/ietf-wg-gnap/general/wiki/Payments > > There was also a discussion in the first BoF about a use case where the > interaction with the AS isn=E2=80=99t to gather consent or =E2=80=9Clog i= n to the client=E2=80=9D > as is typical, but instead to gather additional information needed for th= e > client to complete the request at the API. This was framed with an exampl= e > of collecting credit card payment details, but I think the concept of =E2= =80=9CI > need the current user to come to a web page for a bit=E2=80=9D generalize= s to a lot > of different things. It=E2=80=99s still delegation, between the user and = the > client, but it=E2=80=99s not a =E2=80=9Cgrant=E2=80=9D unless you really = look at it funny. > > There=E2=80=99s not a lot being =E2=80=9Cgranted=E2=80=9D here, in my vie= w of things, and that=E2=80=99s a > part of why I am in favor of having a more precise definition for the ter= m > =E2=80=9Cgrant=E2=80=9D instead of using it as a blanket to cover everyth= ing within the > protocol. > > =E2=80=94 Justin > > On Aug 12, 2020, at 12:43 PM, Fabien Imbault > wrote: > > Hi Dick, > > Maybe to make that discussion more concrete, what else do you imagine > could be exchanged (beyond resource & idclaims)? A few examples? > > Cheers > Fabien > > > > On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt wrote: > >> What is being granted is whatever is being negotiated between the Grant >> Server and the Grant Client -> Which fits into the name of the WG, Grant >> Negotiation and Authorization Protocol, allows us to have names that are >> specific and precise for the roles (Grant Server and Grant Client rather >> than Requesting Party), and is usable by an extension that wants to >> negotiate some new thing between the two roles. >> >> I introduced the term "Grant" in XAuth to mean what the client requested= , >> and what the "server" provided, which included both resource access and >> identity claims. You are narrowly defining grant to ONLY mean "access to >> something". Sometimes I think you just want to disagree with me. :) >> >> I'd be interested in hearing from others! >> >> >> >> In the current drafts, that is resource access and identity claims. >> >> =E1=90=A7 >> >> On Wed, Aug 12, 2020 at 8:58 AM Justin Richer wrote: >> >>> What is being granted is access to something. This makes sense in terms >>> of rights bound to an access token, but I would argue it makes less sen= se >>> for things returned directly. >>> >>> Since you and I also disagree on whether returning things directly is a= n >>> important distinction (even though both the XAuth and XYZ proposals mak= e >>> this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d wa= nt to extend the >>> notion of =E2=80=9Cgrant=E2=80=9D to include anything and everything in= the request and >>> response. >>> >>> I am arguing for it being more specific and precise. >>> >>> =E2=80=94 Justin >>> >>> On Aug 11, 2020, at 6:08 PM, Dick Hardt wrote: >>> >>> A grant is whatever the client is asking from the server. Currently we >>> have access to resources and identity claims. It could contain anything >>> else an extension adds that a client may request from a server. >>> >>> Given the definition of grant that I included, why is grant not the >>> right term to use for this? >>> >>> >>> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer wrote: >>> >>>> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said= that your >>>> definition of it was problematic. Namely, the desire to lump in claims >>>> about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: >>>> >>>> I agree that orchestrator may be a role in the protocol -- it is not a >>>> role in XYZ or XAuth today. >>>> >>>> Justin: would you explain why you think the term "grant" is >>>> problematic? It is in the WG name! >>>> >>>> The client is receiving more than access to resources from the GS, it >>>> is also receiving claims, so "client of the resource" is too limiting. >>>> >>>> Reading the definition of grant[1], it fits as a verb of what the GS i= s >>>> doing, and fits as a noun of what the GS provides to the client. >>>> >>>> A Grant Server is an Authorization Server in OAuth, and an OpenID >>>> Provider in OpenID Connect. >>>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID >>>> Connect. >>>> >>>> Having new terms (GS and GC) in GNAP, separating the roles from OAuth >>>> and OpenID Connect. >>>> It is straightforward to know what a GC and GS do when you understand >>>> that a grant is a combination of resource access (from OAuth) and clai= ms >>>> (from OpenID Connect). >>>> >>>> /Dick >>>> >>>> [1] https://www.dictionary.com/browse/grant >>>> verb (used with object) >>>> to bestow or confer, especially by a formal act:to grant a charter. >>>> to give or accord:to grant permission. >>>> to agree or accede to:to grant a request. >>>> to admit or concede; accept for the sake of argument:I grant that >>>> point. >>>> SEE MORE >>>> noun >>>> something granted, as a privilege or right, a sum of money, or a tract >>>> of land:Several major foundations made large grants to fund the >>>> research project. >>>> the act of granting. >>>> >>>> >>>> [1] >>>> >>>> >>>> >>>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote= : >>>> >>>>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what th= e classical >>>>> =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2= =80=9Corchestrator=E2=80=9D fits with the >>>>> =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been brought up h= ere before, so I=E2=80=99m inclined to >>>>> believe it can be a separate role from the client. >>>>> >>>>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing a= s it is not a >>>>> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of= the resource=E2=80=9D. >>>>> >>>>> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D >>>>> and that=E2=80=99s just going to muddle everything. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >>>>> >>>>> I echo Mike's comments on preserving names when possible. The shift >>>>> from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to ma= ny. >>>>> >>>>> I also echo Tom's comments about separating Entities from Roles. >>>>> >>>>> Orchestration[1] in my opinion is not what the "client" is doing. >>>>> >>>>> Below is a stab at separating the entities and the roles >>>>> >>>>> /Dick >>>>> >>>>> *Tl;dr: * >>>>> - Client -> Grant Client >>>>> - added Relying Party, Claims Issuer, and Grant Server Operator as >>>>> entities >>>>> >>>>> *Roles* - parties to the protocol >>>>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>>> >>>>> *Entities* - parties to a Trust Framework >>>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server >>>>> Operator (GSO), Resource Owner (RO) >>>>> >>>>> *Grant *- may contain claims and/or access to resources >>>>> >>>>> *#Protocol Roles* >>>>> >>>>> *Grant Client* (GC) >>>>> - used by User >>>>> - operated / provided by RP >>>>> - requests Grants from the GS >>>>> - access resources at an RS >>>>> - consumes Claims >>>>> >>>>> *Grant Server* (GS) >>>>> - operated by GSO >>>>> - may interact with the User >>>>> - may interact with the RO >>>>> - accepts grant requests from GCs >>>>> - issues grants to GCs >>>>> - may issue claims >>>>> >>>>> *Resource Server* (RS) >>>>> - manages access to resources for the RO >>>>> - provides access to resources for the GC >>>>> - accepts access granted by the GS >>>>> >>>>> *#Legal Entities* >>>>> >>>>> *User* >>>>> - uses Grant Client >>>>> - may interact with the Grant Server >>>>> - may also be a RO >>>>> - trusts RP, Issuer, GSO >>>>> >>>>> *Relying Party* (RP) >>>>> - provides Grant Client to the User. >>>>> - may trust Issuers, GSOs, and ROs >>>>> >>>>> *Claims Issuer* (Issuer) >>>>> - issues claims to RP >>>>> - may use GS or RS to issue claims >>>>> >>>>> *Grant Server Operator* (GSO) >>>>> - operates the GS >>>>> - trusted by User, RP, and RO >>>>> - may also be an Issuer >>>>> >>>>> *Resource Owne*r (RO) >>>>> - owns resources at the RS >>>>> - trusts GSO to control access to the resources >>>>> - may be same entity as the User >>>>> - may also be an Issuer >>>>> >>>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >>>>> >>>>> Orchestration (computing) >>>>> From Wikipedia, the free encyclopedia >>>>> Jump to navigation >>>>> Jump >>>>> to search >>>>> >>>>> In system administration >>>>> , *orchestration= * is >>>>> the automated configuration >>>>> , >>>>> coordination, and management of computer systems and software >>>>> .[1] >>>>> >>>>> A number of tools exist >>>>> for >>>>> automation of server configuration and management, including Ansible >>>>> , Puppet >>>>> , Salt >>>>> , Terraform >>>>> ,[2] >>>>> >>>>> and AWS CloudFormation >>>>> .[3] >>>>> >>>>> Usage[edit >>>>> >>>>> ] >>>>> Orchestration is often discussed in the context of service-oriented >>>>> architecture >>>>> , >>>>> virtualization >>>>> , provisioning , converge= d >>>>> infrastructure >>>>> and dynamic >>>>> datacenter topics. >>>>> Orchestration in this sense is about aligning the business request wi= th the >>>>> applications, data, and infrastructure.[4] >>>>> >>>>> In the context of cloud computing >>>>> , the main difference >>>>> between workflow automation >>>>> and orchestration >>>>> is that workflows are processed and completed as processes within a s= ingle >>>>> domain for automation purposes, whereas orchestration includes a work= flow >>>>> and provides a directed action towards larger goals and objectives.[1= ] >>>>> >>>>> In this context, and with the overall aim to achieve specific goals >>>>> and objectives (described through quality of service >>>>> parameters), for >>>>> example, meet application performance goals using minimized cost[5] >>>>> and >>>>> maximize application performance within budget constraints.[6] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>>> One of the things that people hated about OAuth was it invented new >>>>>> terminology that wasn=E2=80=99t in common use. But for better or fo= r worse, the >>>>>> terms Client, Authorization Server, and Protected Resource are now w= idely >>>>>> understood. >>>>>> >>>>>> >>>>>> >>>>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even = more >>>>>> novel terms, when existing terms will fit the bill. Client wasn=E2= =80=99t a >>>>>> perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the voca= bulary menagerie would >>>>>> definitely make things worse. >>>>>> >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> >>>>>> *From:* TXAuth *On Behalf Of *Tom Jones >>>>>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>>>>> *To:* Dave Tonge >>>>>> *Cc:* Francis Pouatcha ; Justin Richer < >>>>>> jricher@mit.edu>; Dick Hardt ; Benjamin Kaduk = < >>>>>> kaduk@mit.edu>; Fabien Imbault ; Denis < >>>>>> denis.ietf@free.fr>; txauth@ietf.org >>>>>> *Subject:* Re: [GNAP] Terminology >>>>>> >>>>>> >>>>>> >>>>>> the term "orchestator" does not match any use case i have. >>>>>> >>>>>> Let's be clear that there are four entities to a single transaction >>>>>> in the real world sense of things. (and others that support the >>>>>> transaction.) >>>>>> >>>>>> Then we can focus on the end point roles. I will focus on the data >>>>>> privacy issues, API's have the same parties with different terminolo= gy. >>>>>> >>>>>> 1. the subject of the data to be transferred. >>>>>> >>>>>> 2. the user of a grant from the subject to act as delegate. (see >>>>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable >>>>>> the user) >>>>>> >>>>>> 3. the site that has a repository of user data with legal obligation= s >>>>>> to protect that data (the GDPR) (role resource server.) >>>>>> >>>>>> 4 the site that wants either access to the data, or some privacy >>>>>> preserving statement about the existence and content of the data. (r= ole of >>>>>> client, vendor, PISP, etc.) >>>>>> >>>>>> 5. some sorts of facilitator sites for allowing access (roles like >>>>>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have be= en left >>>>>> out of OAUTH for good reason. >>>>>> >>>>>> >>>>>> >>>>>> This is a note supporting the separation of roles from legal >>>>>> entities. BTW, I firmly believe that the legal entity also needs to= be >>>>>> ID'd by the transaction. >>>>>> >>>>>> Peace ..tom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>>>>> wrote: >>>>>> >>>>>> Hi all >>>>>> >>>>>> >>>>>> >>>>>> I agree that "client" can be confusing. I would be in support of >>>>>> alternative terminology. >>>>>> >>>>>> We can always have some wording that explains that an "Orchestrator" >>>>>> in GNAP plays a similar role to "Client" in OAuth. >>>>>> >>>>>> >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Hi Francis, >>>>>> >>>>>> >>>>>> >>>>>> I like your proposal, seems much more intuitive. >>>>>> >>>>>> >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> >>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>>>>> =C3=A9crit : >>>>>> >>>>>> Hello Denis, Justin, Dick, Fabien, >>>>>> >>>>>> >>>>>> >>>>>> In this post ( >>>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-J= OGNw/) >>>>>> i suggested we use the word "Orchestrator" to designate the piece of >>>>>> software that orchestrate interaction between "Requestor" (a.k.a. Us= er), AS >>>>>> and RS to obtain the protected resource. >>>>>> >>>>>> >>>>>> >>>>>> We are turning around the same topic. As soon as we go beyond the >>>>>> original oAuth protocol, the word 'Client' becomes confusing. >>>>>> >>>>>> >>>>>> >>>>>> In the same response, I suggest we talk about "roles" and not >>>>>> "entities". >>>>>> >>>>>> >>>>>> >>>>>> Best regards. >>>>>> >>>>>> /Francis >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>> I still think that client was the right name in OAuth 2, as the >>>>>> client wanted to do a client-server interaction, so the client used = OAuth 2 >>>>>> to get an access token to interact with the "server". >>>>>> >>>>>> >>>>>> >>>>>> I do agree that it is not the best term in GNAP. Primarily because >>>>>> GNAP is a combination of the client from OAuth 2, and the relying pa= rty >>>>>> from OIDC. >>>>>> >>>>>> >>>>>> >>>>>> /Dick >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote= : >>>>>> >>>>>> >>>>>> >>>>>> The term client in OAuth came from the computer science definition o= f >>>>>> client-server interaction. >>>>>> >>>>>> >>>>>> >>>>>> This, I would argue, is exactly why it=E2=80=99s a bad label for som= ething >>>>>> that=E2=80=99s distinctly more specific in this context, and I would= love to see >>>>>> GNAP adopt a more specific label for the role that we traditionally = called >>>>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The client is getting an access token so it can call a server, >>>>>> specifically, a resource server (to differentiate it from the author= ization >>>>>> server). >>>>>> >>>>>> >>>>>> >>>>>> The confusion in my experience usually stems from people working wit= h >>>>>> software that is acting in multiple roles. IE, the software that is = acting >>>>>> as a client in once context, is also acting as an RS in other contex= ts, or >>>>>> even acting as an AS. The other confusion is that people view client= s as >>>>>> being the software the user is using -- although it may not be actin= g as a >>>>>> client in the oauth context. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> To me, client has always been a strange word in the context of OAuth= , >>>>>> as it has a meaning well defined both in everyday life (this client = is a >>>>>> good customer) and in computer science (client-server interaction). = Thus I >>>>>> always have to make the mental translation to the OAuth world before= any >>>>>> discussion... And any teaching experience shows that it does make th= e >>>>>> concepts hard to grasp for a majority of (clever) people. >>>>>> >>>>>> >>>>>> >>>>>> As for the RO, previous discussions suggested Resource >>>>>> Controller (RC) also, which may be a bit more specific than manager. >>>>>> >>>>>> >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>>>> >>>>>> Justin and Dick, >>>>>> >>>>>> >>>>>> >>>>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>>>> the creation of OAuth)"] >>>>>> >>>>>> >>>>>> >>>>>> So let us attempt to define new terms: >>>>>> >>>>>> *initiating application (IA)*: application by means of which a user >>>>>> initiates interactions with RS(s) and AS(s) >>>>>> >>>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>>> which is currently defined as: >>>>>> >>>>>> Resource Owner (RO): entity capable of granting access to a protecte= d >>>>>> resource >>>>>> >>>>>> I propose to replace it with Resource Manager (RM): >>>>>> >>>>>> *Resource Manager (RM)* : application or user that manages an access >>>>>> decision function of a Resource Server >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> I agree with Justin. Redefining well used terms will lead to >>>>>> significant confusion. If we have a different role than what we have= had >>>>>> in the past, then that role should have a name not being used alread= y in >>>>>> OAuth or OIDC. >>>>>> >>>>>> >>>>>> >>>>>> Given what we have learned, and my own experience explaining what a >>>>>> Client is, and is not, improving the definition for Client could pro= ve >>>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>>> >>>>>> >>>>>> >>>>>> For example, clarifying that a Client is a role an entity plays in >>>>>> the protocol, and that the same entity may play other roles at other= times, >>>>>> or some other language to help differentiate between "role" and "ent= ity". >>>>>> >>>>>> >>>>>> >>>>>> /Dick >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote= : >>>>>> >>>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a b= etter fit, but >>>>>> I=E2=80=99m not really in favor of taking an existing term and apply= ing a >>>>>> completely new definition to it. In other words, I would sooner stop= using >>>>>> =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and a= ccurate term for the >>>>>> role than to define =E2=80=9Cclient=E2=80=9D as meaning something co= mpletely different. We >>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the >>>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cser= ver=E2=80=9D on its own but instead >>>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>>> >>>>>> >>>>>> >>>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>>> ignore the fact that GNAP is going to be coming up in a world that i= s >>>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank >>>>>> slate to work with, but neither are we bound to use the same terms a= nd >>>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> >>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>>> >>>>>> >>>>>> >>>>>> I think that is fundamentally part of the question: >>>>>> >>>>>> We are clear that we are producing a protocol that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusin= g >>>>>> terms >>>>>> from OAuth 2.0 but with different definitions may lead to unnecessar= y >>>>>> confusion >>>>>> >>>>>> >>>>>> >>>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>>> should not change the meanings of any definition. If we are saying t= his >>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick t= he best >>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I h= ave a >>>>>> lot of first hand experience of industries "ruining words", and atte= mpting >>>>>> to side-step the problem rather than redefining the word just confus= es >>>>>> everyone as everyone forgets the original meaning as new documents c= ome >>>>>> out, but the confusion with the use of a non-obvious word continues. >>>>>> >>>>>> >>>>>> >>>>>> Food for thought. >>>>>> >>>>>> - Warren >>>>>> >>>>>> >>>>>> *Warren Parad* >>>>>> >>>>>> Founder, CTO >>>>>> >>>>>> Secure your user data and complete your authorization architecture. >>>>>> Implement Authress . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>>>> >>>>>> Hi Denis, >>>>>> >>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>> > Hi Justin, >>>>>> > >>>>>> > Since you replied in parallel, I will make a response similar to >>>>>> the one >>>>>> > I sent to Dick. >>>>>> > >>>>>> > > Hi Denis, >>>>>> > > >>>>>> > > I think there=E2=80=99s still a problem with the terminology in = use here. >>>>>> What >>>>>> > > you describe as RS2, which might in fact be an RS unto itself, i= s >>>>>> a >>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clie= nt of RS1/. What >>>>>> you >>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth wor= ld, but it is not >>>>>> at >>>>>> > > all the same as an OAuth client. I appreciate your mapping of th= e >>>>>> > > entities below, but it makes it difficult to hold a discussion i= f >>>>>> we >>>>>> > > aren=E2=80=99t using the same terms. >>>>>> > > >>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can >>>>>> define >>>>>> > > our own terms. The bad news is that this is really hard to do. >>>>>> > > >>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with ne= w >>>>>> definitions, >>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we de= fine >>>>>> things. >>>>>> > >>>>>> > In the ISO context, each document must define its own terminology. >>>>>> The >>>>>> > boiler plate for RFCs does not mandate a terminology or definition= s >>>>>> section >>>>>> > but does not prevent it either. The vocabulary is limited and as >>>>>> long as >>>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>>> already >>>>>> > used in another RFC. This is also the ISO approach. >>>>>> >>>>>> Just because we can do something does not necessarily mean that it i= s >>>>>> a >>>>>> good idea to do so. We are clear that we are producing a protocol >>>>>> that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusin= g >>>>>> terms >>>>>> from OAuth 2.0 but with different definitions may lead to unnecessar= y >>>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>>> Dick to >>>>>> use the term "GS" in XAuth, picking a name that was not already used >>>>>> in >>>>>> OAuth 2.0. >>>>>> >>>>>> -Ben >>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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/ >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at https://register.fca.org= .uk/ >>>>>> . Moneyhub Financial Technology is reg= istered >>>>>> in England & Wales, company registration number 06909772. Moneyhub >>>>>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus = Building, >>>>>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>> >>>> >>> > --0000000000005f556905acbf3945 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot.=C2=A0=C2=A0

Terminology is hard and so I'm thankful for an= yone that submits a definition or provides constructive criticism ;-)
=
I think we shouldn't try to be perfect from the=C2=A0start (and pr= obably never will be). What matters is that we gradually try to clarify wha= t we mean within our context, and as much as possible, but be careful not u= se a usual term in a completely different way (changes to well accepted ter= ms should be limited to the extreme).=C2=A0

In tha= t sense, starting from the dictionary is a good idea, as per Dick's pro= posal.=C2=A0

Two of the verb definitions fit quite= well to our objectives, without change.=C2=A0 =C2=A0
to give or= accord -> fits well with the token generation (accord) and dispatch (gi= ve)=C2=A0 =C2=A0
to agree or accede to -> fits well with the consen= t phase=C2=A0=C2=A0
(the other 2 definitions are irrelevant to o= ur scope)

The original definition of grant (as a n= oun) is already enabling some extensibility ("something granted= , as a privilege or right, a sum of money, or a tract of land"). That = could come handy!
- privilege: pretty much what we expect fro= m an identity claim
- right: what we expect from an access token<= /div>
- sum of money:similar to the=C2=A0https://github.com/ie= tf-wg-gnap/general/wiki/Payments=C2=A0use case.=C2=A0=C2=A0
- tract of land: a bit more alien (https://www.lawinsider.com/dic= tionary/tract-of-land), but maybe related to the "Signing contract= s" example of the previous use case? Unsure about this one, I tentativ= ely propose something in the definition that comes afterwards.=C2=A0
<= div>
Probably a rewording is necessary, but it seems to cover= a large part of what we are looking for.=C2=A0

So= here's what I would propose as a starting point:=C2=A0

<= /div>
GRANT (verb)
to give or accord
Example: to= grant permission.
to agree or accede to
Example: to grant consent.
Note: in the GNAP protocol, the act = of granting generally involves automated processes (by computers) and human= interactions through a web browser.=C2=A0

<= /div>
GRANT (noun)
something granted, as a privileg= e or right, a sum of money or as the outcome of an obligation or a promise<= /i>
Example 1: digital access token to a protected resource.
Example 2: privilege derived from an identity claim.
Example 3: a sum of money granted by the customer to a service p= rovider, as the result of a payment flow initiated at the retail store or v= ia ecommerce.
Example 4: access right to open and drive a = car, from a car sharing company (by contract) or from a relative (by promis= e).=C2=A0
Note: in the GNAP protocol, a grant is negotiate= d between a <Client> and a grant server and usually involves the proc= essing and exchange of identity claims and/or access tokens.
<= div>
<Client> =3D term to be changed=C2=A0

Any feedback welcome.

=
Le mer= . 12 ao=C3=BBt 2020 =C3=A0 19:29, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
Fabien,

There have been a n= umber of additional applications that are getting discussed. One concrete e= xample is a payments system as written up here:

https://github.com/ietf-wg-gnap/general/wiki/Paym= ents

There was also a discussion in the first = BoF about a use case where the interaction with the AS isn=E2=80=99t to gat= her consent or =E2=80=9Clog in to the client=E2=80=9D as is typical, but in= stead to gather additional information needed for the client to complete th= e request at the API. This was framed with an example of collecting credit = card payment details, but I think the concept of =E2=80=9CI need the curren= t user to come to a web page for a bit=E2=80=9D generalizes to a lot of dif= ferent things. It=E2=80=99s still delegation, between the user and the clie= nt, but it=E2=80=99s not a =E2=80=9Cgrant=E2=80=9D unless you really look a= t it funny.

There=E2=80=99s not a lot being =E2=80= =9Cgranted=E2=80=9D here, in my view of things, and that=E2=80=99s a part o= f why I am in favor of having a more precise definition for the term =E2=80= =9Cgrant=E2=80=9D instead of using it as a blanket to cover everything with= in the protocol.=C2=A0

=C2=A0=E2=80=94 Justin
<= div>
On Aug 12, 2020, at 12:43 PM, Fabien= Imbault <fabien.imbault@gmail.com> wrote:

Hi Dick,=C2=A0

Maybe to make that discuss= ion more concrete, what else do you imagine could be exchanged (beyond reso= urce & idclaims)? A few examples?

Cheers
=
Fabien=C2=A0



On Wed, Aug 12, 2020= at 6:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
What is b= eing granted is whatever is being negotiated between the Grant Server and t= he Grant Client -> Which fits into the name of the WG, Grant Negotiation= and Authorization Protocol, allows us to have names that are specific and = precise for the roles (Grant Server and Grant Client rather than Requesting= Party), and is usable by an extension that wants to negotiate some new thi= ng between the two roles.=C2=A0

I introduced the term &q= uot;Grant" in XAuth to mean what the client requested, and what the &q= uot;server" provided, which included both resource access and identity= claims. You are narrowly defining grant to ONLY mean "access to somet= hing". Sometimes I think you just want to disagree with me. :)

I'd be interested in hearing from others!
<= /div>



In the current = drafts, that is resource access and identity claims.=C2=A0

=E1=90=A7

On Wed, Aug 12, 2020 at 8:58 AM Ju= stin Richer <jricher@mit.edu> wrote:
What is being granted is access to somethi= ng. This makes sense in terms of rights bound to an access token, but I wou= ld argue it makes less sense for things returned directly.

Since you and I also disagree on whether returning things directly is an= important distinction (even though both the XAuth and XYZ proposals make t= his distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d want to= extend the notion of =E2=80=9Cgrant=E2=80=9D to include anything and every= thing in the request and response.=C2=A0

I am argu= ing for it being more specific and precise.

=C2=A0= =E2=80=94 Justin

On Aug 11, 2020= , at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
A grant is whatever the client is asking from the se= rver. Currently we have access to resources and identity claims. It could c= ontain anything else an extension adds that a client may request from a ser= ver.

Given the definition of grant that I included, why = is grant not the right term to use for this?


=
On Tue, Au= g 11, 2020 at 1:35 PM Justin Richer <jricher@mit.edu> wrote:
I did not say the = term =E2=80=9Cgrant=E2=80=9D was problematic, I said that your definition o= f it was problematic. Namely, the desire to lump in claims about the user i= nto the definition of the =E2=80=9Cgrant=E2=80=9D.=C2=A0

=C2=A0=E2=80=94 Justin

On Aug 1= 1, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that orchestrator may be a role in th= e protocol -- it is not a role in XYZ or XAuth today.

Ju= stin: would you explain why you think the term "grant" is problem= atic? It is in the WG name!

The client is receivin= g=C2=A0more than access to resources from the GS, it is also receiving=C2= =A0claims, so "client of the resource" is too limiting.

Reading the definition of grant[1], it fits as a verb of wh= at the GS is doing, and fits as a noun of what the GS provides to the clien= t.

A Grant Server is an Authorization Server in OA= uth, and an OpenID Provider in OpenID Connect.
The Grant Client i= s a Client in OAuth, and a Relying Party in OpenID Connect.

<= /div>
Having new terms (GS and GC) in GNAP, separating the roles from O= Auth and OpenID Connect.
It is straightforward=C2=A0to know what = a GC and GS do when you understand that=C2=A0a grant is a combination of re= source access (from OAuth) and claims (from OpenID Connect).

=
/Dick

verb (used with object)

to bestow or= confer, especially by a formal act:to grant = a charter.
to give or accord:to grant permission.
to agree or accede to:to grant a request.
to admit or concede; a= ccept for the sake of argument:I grant that p= oint.

noun

something granted, as a privilege or right, a sum of mone= y, or a tract of land:Several major foundatio= ns made large grants to fund the research project.
the act= of granting.


<= /div>
[1]=C2=A0



On Tue, Aug 11, 2020= at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
I agree that =E2=80=9Corche= stration=E2=80=9D is separate from what the classical =E2=80=9Cclient=E2=80= =9D in OAuth is doing =E2=80=94 but the term =E2=80=9Corchestrator=E2=80=9D= fits with the =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been bro= ught up here before, so I=E2=80=99m inclined to believe it can be a separat= e role from the client.

I personally think that =E2=80= =9Cgrant client=E2=80=9D is confusing as it is not a =E2=80=9Cclient of the= grant=E2=80=9D but rather a =E2=80=9Cclient of the resource=E2=80=9D.

I also think it=E2=80=99s problematic to lump in user = claims with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s just going to mudd= le everything.=C2=A0

=C2=A0=E2=80=94 Justin

On Aug 11, 2020, at 3:25 PM, Dick Hard= t <dick.hardt@gmail.com> wrote:

=
I echo Mike's comments= on preserving names when possible. The shift from "consumer" in = OAuth 1 to "client" in OAuth 2 was confusing to many.

I also echo Tom's comments about separating Entities = from Roles.

Orchestration[1] in my opinion is not = what the "client" is doing.

Below is a s= tab at separating the entities and the roles

/Dick=

Tl;dr:=C2=A0
- Client=C2=A0->= Grant Client
- added Relying Party, Claims Issuer, and Grant Ser= ver Operator as entities

Roles - parti= es to the protocol
Grant Client (GC), Grant Server (GS), Resource= Server (RS)

Entities - pa= rties to a Trust Framework
User, Relying Party (RP), Claims Issuer (Iss= uer), Grant Server Operator (GSO), Resource=C2=A0Owner (RO)

Grant -=C2=A0may contain claims and/or ac= cess to resources

#Protocol Roles

Grant Client (GC)
- used by User
- operated / provided by RP
- requests Grants from the GS
<= div>- access resources at an RS
- consumes Claims

<= /div>
Grant Server (GS)
- operated by GSO
- = may interact with the User=C2=A0
- may interact with the RO
=
- accepts grant requests from GCs
- issues grants to GCs
- may issue claims

Resource Server = (RS)
- manages access to resources for the RO
- provide= s access to resources for the GC
- accepts access granted by the = GS

#Legal Entities

User
- uses Grant Client
- may interact with th= e Grant Server
- may also be a RO
- trusts RP, Issuer, = GSO

Relying Party (RP)
- provides= Grant Client to the User.
- may trust Issuers, GSOs, and ROs

Claims Issuer (Issuer)
- issues cla= ims to RP
- may use GS or RS to issue claims

=
Grant Server Operator (GSO)
- operates the GS
- trusted by User, RP, and RO
- may also be an Issuer

Resource Owner (RO)
- owns resourc= es at the RS
- trusts GSO to control access to the resources
- may be same entity as the User
- may also be an Issu= er

<= div>

O= rchestration (computing)

From Wikipedia, the free encyclopedia
Jump to navigationJump to search
In=C2=A0system administration,=C2=A0orchestration=C2=A0is the automate= d=C2=A0configu= ration, coordination, and management of computer systems and=C2=A0software.[1]
A=C2=A0<= a href=3D"https://en.wikipedia.org/wiki/Category:Orchestration_software" ti= tle=3D"Category:Orchestration software" style=3D"text-decoration-line:none;= color:rgb(11,0,128);background:none" rel=3D"noreferrer" target=3D"_blank">n= umber of tools exist=C2=A0for automation of server configuration and ma= nagement, including=C2=A0A= nsible,=C2=A0Puppet,= =C2=A0Salt,=C2=A0Terraform,[2]=C2=A0and=C2=A0AWS CloudFormation.[3]

Usage[edit]

Orchestration is often discussed in the context of=C2=A0servic= e-oriented architecture,=C2=A0virtualization,=C2=A0provisioning,=C2=A0converged infrastructure=C2=A0and dynamic=C2=A0datacenter=C2=A0topics. Orchestration in this se= nse is about aligning the business request with the applications, data, and= infrastructure.<= a href=3D"https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note= -4" style=3D"text-decoration-line:none;color:rgb(11,0,128);background:none"= rel=3D"noreferrer" target=3D"_blank">[4]
In the context of=C2=A0cloud computing, the main difference between=C2=A0workflow automation=C2=A0and orchest= ration is that workflows are processed and completed as processes within a = single domain for automation purposes, whereas orchestration includes a wor= kflow and provides a directed action towards larger goals and objectives.[1]
In this context, and with the overall aim to achieve specific goals a= nd objectives (described through=C2=A0quality of service=C2=A0parameters), for example, meet appl= ication performance goals using minimized cost[5]=C2=A0and maximize application perfor= mance within budget constraints.[6]




=



On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jone= s@microsoft.com> wrote:

One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

=C2=A0

Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

= From: TXAuth <txauth-bounces@ietf.org> On Behalf O= f Tom Jones
Sent: Tuesday, August 11, 2020 8:44 AM
To: Dave Tonge <dave.tonge@moneyhub.com>
Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@= mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Ka= duk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com= >; Denis <denis.ietf@free.fr>; txauth@ietf.org
Subject: Re: [GNAP] Terminology

=C2=A0

the term "orchestator" does not match= any use case i have.

Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

1. the subject of the data to be transferred.

2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation= for how to enable the user)

3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

=C2=A0

This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

Peace ..tom

=C2=A0

=C2=A0

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@moneyhub.com> wrote:

Hi all

=C2=A0

I agree that "client" can be confusing. I would = be in support of alternative terminology.

We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

=C2=A0

Dave

=C2=A0

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imbault@gmail.com> wrote:

Hi Francis,

=C2=A0

I like your proposal, seems much more intuitive= .=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:

Hello Denis, Justin, Dick, Fabien,

=C2=A0

In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOB= JqdmQY-JOGNw/) i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

=C2=A0

We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

=C2=A0

In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

=C2=A0

Best regards.

/Francis

=C2=A0

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" rel=3D"noreferrer" target=3D"_blank"= >dick.hardt@gmail.com> wrote:

I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

=C2=A0

I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

=C2=A0

/Dick

=E1=90=A7<= /span>

=C2=A0

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;= jricher@mit.edu> wrote:

On Aug 6, 2020, at 12:53 PM, Dick Hardt <d= ick.hardt@gmail.com> wrote:

=C2=A0

The term client in OAuth came from the computer= science definition of client-server interaction.

=C2=A0

This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

=C2=A0

=C2=A0=E2=80=94 Justin



=C2=A0

The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

=C2=A0

The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7<= /span>

=C2=A0

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imbault@gmail.com> wrote:

Hi,=C2=A0

=C2=A0

To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

=C2=A0

As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

=C2=A0

Fabien=C2=A0

=C2=A0

On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.= ietf@free.fr> wrote:

Ju= stin and Dick,

=C2=A0

[W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

=C2=A0

So= let us attempt to define new terms:

initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

Re= source Owner (RO): entity capable of granting access to a protected resourc= e

I = propose to replace it with Resource Manager (RM):

Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

D= enis

=C2=A0

I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

=C2=A0

Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

=C2=A0

For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

=C2=A0

/Dick

=E1=90=A7<= /span>

=C2=A0

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;j= richer@mit.edu> wrote:

I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

=C2=A0

GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0

=C2=A0=E2=80=94 Justin



On Aug 4, 2020, at 3:32 PM, Warren Parad <wpar= ad@rhosys.ch> wrote:

=C2=A0

I think that is fundamentally part of the quest= ion:

We are clear that we are prod= ucing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

=C2=A0

If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

=C2=A0

Food for thought.

- Warren

Warren Parad<= u>

Founder, CTO=

Secure your u= ser data and complete your authorization architecture. Implement=C2=A0<= span style=3D"font-size:10pt">Authress.

=C2=A0

=C2=A0

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;ka= duk@mit.edu> wrote:

Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>

--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>

=C2=A0

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>

=C2=A0

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>

=C2=A0

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>


=C2=A0

--

Francis Pouatcha

Co-Founder and Technical Lead

adorsys GmbH & Co. KG

--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>

=C2=A0

=C2=A0

Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= u>





--0000000000005f556905acbf3945-- From nobody Thu Aug 13 05:59:10 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 7C4463A0BFC for ; Thu, 13 Aug 2020 05:59:09 -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=moneyhub.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 G7p0SKDkddS2 for ; Thu, 13 Aug 2020 05:59:07 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 D3A5D3A0BFF for ; Thu, 13 Aug 2020 05:59:07 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id f10so2583919plj.8 for ; Thu, 13 Aug 2020 05:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iq/eMFQoUmQKRh2QXHUIG/S94FRpNtXVT6LeMg8HAAM=; b=XApJOiIYC6KLtxqmN08D96Rf/4gl1zGgyGN5LrchoxG9z7xpz9aAwWrMziYS1Isuaf 8cy09sB/du3M15Mr1SME0NOE4cdjDkMbYcOm3HHWvZQLTGv9gzSewMxPGXKmVqOI/c8N eyID+dlBjvYH0MLr/9C5BZOGAF2AR9oBfLy4Q= 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=Iq/eMFQoUmQKRh2QXHUIG/S94FRpNtXVT6LeMg8HAAM=; b=tvSeVdreJMXwtxrULfKu2jDrvRrsJjUcCANwxy1Qr+n6uFBGEr6yhi6TTB+qe3qv2q ivK1Gs789oDYLQqhGtLevIktiMy5ITbymBLEl2wcaqnQDy4kwR535Y+qJNApHNQO2B3L X9EzD9Dzm3eOm78ztE6G/xpKPC8xZvIaS8hFNuUw+Snta/oz7kuJVT+fsV6kxOKtxZe8 2vzr2y3WSzMDEs7nhl8LVhrTKcgkekm6in+WqQw5043PvtzCRGosC9vgeXuvUmgcSn4y YnxFnzP7u5Ny49O558Fz8f/gRF680QRRvihGflxHdK7lX/FZqJR3ohBvCilMf9El7knT rvDQ== X-Gm-Message-State: AOAM532ZmmiDeDj6KzYr9yJX/b5xDy92Z1Mc8cCwjYE1+YSIGi5BEJSU HmO/HFwCdzt4VN+8rTd0D1RIVg2Ggpi+JtNLQaPLLrQMZZuXWgqk18vGX1lCnhH43NyBbpxmgxZ A6O+B8U/5KbQC3oU= X-Google-Smtp-Source: ABdhPJx9N2meuDiMw1eNiQ364kpFgFqR1Vvp6LmwCRb8zB8tXu6eyKCKVd4LrrC7Ki2aZuKJTYLVITXW9nRDCa9WNHE= X-Received: by 2002:a17:90b:1295:: with SMTP id fw21mr4505016pjb.81.1597323547089; Thu, 13 Aug 2020 05:59:07 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> In-Reply-To: From: Dave Tonge Date: Thu, 13 Aug 2020 14:58:55 +0200 Message-ID: To: Fabien Imbault Cc: Justin Richer , Dick Hardt , Mike Jones , Tom Jones , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009db96205acc1de21" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 13 Aug 2020 12:59:10 -0000 --0000000000009db96205acc1de21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would be against using "grant" as both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant" is in the verb: "granted"). Using it as both a verb and a noun will be confusing and less accessible. I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted" Whether the access takes place via a token being returned and used at a resource server, or "claims" that are directly returned from the "Grant Server" I think should be largely irrelevant when it comes to the naming of the roles. In almost all use cases that I have seen the "Grant Server" is making a policy based decision "to grant" access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to - identity attributes for the end user - verify an identity attribute (e.g. that user is over 18) - all users photos at resource server X - a single photo with id 12345 at resource server Y - resource of type X at any resource server that trusts the Grant Server - call a payment API with specific properties (e.g. amount < 5) - call a file storage API - call a "contract signing" API with specific properties (e.g. contract hash of xxx,) While "client" is problematic, it does now have wide spread usage, so perhaps we are stuck with it. However I agree with Justin and think "Grant Client" makes things more confusing. What is wrong with keeping "Client" and "Authorization Server"? Dave --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --0000000000009db96205acc1de21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 13, 2020 at 2:59 PM D= ave Tonge <dave.tonge@moneyhu= b.com> wrote:
I would be against using "grant&qu= ot; as both a verb and a noun and stick purely with one or the other. (In t= he charter the only use of "grant" is in the verb: "granted&= quot;).

Using it as both a verb and a noun will be confusing and less acc= essible.

I think it will be c= onfusing to say "The Grant Server issues a grant to the Grant Client r= epresenting access that has been granted"

<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">Whether the access takes place via a token being returned and us= ed at a resource server, or "claims" that are directly returned f= rom the "Grant Server" I think should be largely irrelevant when = it comes to the naming of the roles.

=C2=A0- identity=C2=A0attributes for the end user
=C2=A0- verify=C2=A0an identity attribute (e.g. that user is over 18)
=C2=A0- all users photos at resource server X
=C2=A0- a single photo with id 12345 at resource server Y
=C2=A0- resource of type X at any resource server that trusts the Grant = Server
=C2=A0- call a payment API with specific properties= (e.g. amount < 5)
=C2=A0- call a file storage API
=C2=A0- call a "contract signing" API with specific = properties (e.g. contract hash of xxx,)
=C2=A0
While "client" is problematic, it does now have wide spread= usage, so perhaps we are stuck with it.=C2=A0
However= I agree with Justin and think "Grant Client" makes things more c= onfusing.

What is wrong with keeping= "Client" and "Authorization Server"?=C2=A0

Dave



Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--000000000000002d7e05acc29155-- From nobody Thu Aug 13 06:49:28 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 B6E0B3A0C45 for ; Thu, 13 Aug 2020 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nXOb2jHHE5Kd for ; Thu, 13 Aug 2020 06:49:22 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B873A0C43 for ; Thu, 13 Aug 2020 06:49:21 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id F1pK230042bcEcA031pKAT; Thu, 13 Aug 2020 15:49:19 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 15:49:19 +0200 X-ME-IP: 90.79.51.120 To: Justin Richer Cc: Benjamin Kaduk , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> <417CAA5C-3F64-4284-95C6-CA58E07AF7F0@mit.edu> From: Denis Message-ID: <4432c842-ee1c-40bc-1337-0db4cc96dd83@free.fr> Date: Thu, 13 Aug 2020 15:49:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <417CAA5C-3F64-4284-95C6-CA58E07AF7F0@mit.edu> Content-Type: multipart/alternative; boundary="------------278383E0687200691EF3EB4C" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 13:49:27 -0000 This is a multi-part message in MIME format. --------------278383E0687200691EF3EB4C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, > Denis, > > This isn’t mandated, this is one optional flow for the cases where the > RS :wants: to talk to the AS. It is good to know. But what will be the rational(s) for it ? Token introspection ? If this is the single case, since token transparency is needed for privacy reasons, it is doubtful that it would still be needed. If flows can be made simpler, let us make them simpler. Denis > >  — Justin > >> On Aug 12, 2020, at 12:02 PM, Denis > > wrote: >> >> Justin, >> >> A soon as the RS needs to talk to the GS (step 2a) , it is a "Big >> Brother by Design" architecture. >> Do you want to mandate it ? >> >> Denis >> >>> +1 to this. I think that the core protocol needs to be designed to >>> allow this kind of action, but I also think it is possible that the >>> details of this could end up in an extension to the main document. >>> I’ve put a flag in the ground for this in XYZ in sections 10.3 and >>> 10.4, which is adapted from UMA2’s distributed authorization protocol: >>> >>> https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.3 >>> >>> The important detail here, in XYZ’s design, is that the RS has a >>> clear way to communicate to the client what will be needed to >>> fulfill the request, and the client/orchestrator/whatever has a >>> clear way to incorporate that into the main protocol. The details of >>> (2) using the XYZ pattern are: >>> >>> +-----------+     +--------------+  +----+  +----+ >>>  +---------------------+ >>> | Requestor |      | Orchestrator |  |    |  | GS |  | Resource >>> Controller | >>> |  was     |      |     was      |  | RS |  | or |  |         was    >>>      | >>> | User     |      |   Client     |  |    |  | AS |  |    Resource >>> Owner   | >>> +-----------+      +--------------+  +----+  +----+ >>>  +---------------------+ >>>   |(1) ServiceRequest     |            |  |                | >>>   |---------------------->|            |  |                | >>>   |                       |(2) ServiceIntent:AuthZChallenge     | >>>   |                       |----------->|  |                | >>>   |                     |            |       |          | >>>   |                     |            |(2a) Register resource set >>>   |                       | |------>|                | >>> |                       |            |       |               | >>> |                       |            |(2b) Return resource reference >>> handle >>> |                       | |<------|                | >>> |                       |            |       |               | >>> |                       |(2c) Return AS URL and resource reference >>> handle >>> |                       |<-----------|  |                | >>> |                       |            |       |               | >>>   |        |(3) AuthZRequest(AuthZChallenge, include resource handle) >>>   |  |------------------->|                | >>> >>> >>> Note that the client can ALSO request additional resources on top of >>> what the RS returned in (2b), since this is passed simply as one >>> element of the array. >>> >>>  — Justin >>> >>>> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha >>> > wrote: >>>> >>>> Hello Dick, >>>> >>>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt >>> > wrote: >>>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the protocol in how I am >>>> defining roles, so steps (1) and (7) are confusing to me on >>>> what is happening. >>>> >>>> "Requestor" is the role (*was* User). So the UML participant >>>> refers to the role "Requestor" >>>> >>>> >>>> I also think that (2) could be an extension to GNAP, rather >>>> than part of the core protocol. >>>> >>>> If you make it an extension, you hide. It shall rather be an >>>> optional, integral part of the protocol. If the >>>> "Orchestrator/Negotiator/Client" can translate the service request >>>> into a resource request, then there will be no need to invoke (2). >>>> >>>> When we move beyond identity management, cases become complex and >>>> it makes sense to explicitly display this possibility in the >>>> protocol flow. >>>> >>>> In some open banking designs, >>>> - the "Orchestrator/Negotiator/Client" will not know the AS to talk >>>> to unless the call (2). >>>> - the request (2) might result in an exemption, meaning no need for >>>> further authorization, allowing to skip (3, 4, 5) and even (6). >>>> >>>> /Francis >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>>> > wrote: >>>> >>>> In this context, I suggest we pick some words to work with, >>>> and sharpen them as we move on, discover and map new use >>>> cases to the protocol. >>>> >>>> In this diagram from the original thread >>>> (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), >>>> I replaced the words: >>>> >>>> +-----------+     +--------------+  +----+  +----+ >>>>  +---------------------+ >>>> | Requestor |      | Orchestrator |  |    |  | GS |  | >>>> Resource Controller | >>>> |   was  |      |     was      | | RS |  | or |  |        >>>>  was        | >>>> |  User  |      |   Client     |  | |  | AS |  |    >>>> Resource Owner   | >>>> +-----------+ +--------------+  +----+  +----+ >>>>  +---------------------+ >>>>   |(1) ServiceRequest     |         |       |   | >>>> |---------------------->|           |       |     | >>>>   |                       |(2) ServiceIntent:AuthZChallenge >>>>    | >>>>   |  |<---------->|       |               | >>>>   |                       |         |       |   | >>>>   |                       |(3) AuthZRequest(AuthZChallenge) >>>>    | >>>>   |  |------------------->|             | >>>>   |                       |         |       |(4) >>>> ConsentRequest:Grant >>>>   |                       |         |  |<-------------->| >>>>   |                       |(5) GrantAccess(AuthZ)    | >>>>   |  |<-------------------|             | >>>>   |                       |         |       |   | >>>>   |                       |(6) >>>> ServiceRequest(AuthZ):ServiceResponse >>>>   |  |<---------->|       |               | >>>>   |(7) ServiceResponse    |         |       |   | >>>> |<----------------------|           |       |     | >>>>   +                       +         +       +   + >>>> >>>> The purpose of the GNAP protocol is to help negotiate >>>> access to a protected resource. It starts with a requestor >>>> delegating activity to an orchestrator. These are all >>>> roles, no entities. Let focus on mapping the use cases to >>>> the protocol roles and interactions so wwe can discover >>>> what is missing. >>>> >>>> It seems cumbersome to use it in discussions as it is >>>> impossible to give the word "Client" a clear definition. >>>> >>>> We can mention in the final document, that the >>>> "Orchestrator" (or whatever word we finally use) plays the >>>> same role as the "Client" in oAuth2. >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>>> > wrote: >>>> >>>> I agree with Justin. Redefining well used terms will >>>> lead to significant confusion. If we have a different >>>> role than what we have had in the past, then that role >>>> should have a name not being used already in OAuth or >>>> OIDC. >>>> >>>> Given what we have learned, and my own experience >>>> explaining what a Client is, and is not, improving the >>>> definition for Client could prove useful. I am not >>>> suggesting the term be redefined, but clarified. >>>> >>>> For example, clarifying that a Client is a role an >>>> entity plays in the protocol, and that the same entity >>>> may play other roles at other times, or some other >>>> language to help differentiate between "role" and "entity". >>>> >>>> /Dick >>>> ᐧ >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>> > wrote: >>>> >>>> I’m in favor of coming up with a new term that’s a >>>> better fit, but I’m not really in favor of taking >>>> an existing term and applying a completely new >>>> definition to it. In other words, I would sooner >>>> stop using “client” and come up with a new, more >>>> specific and accurate term for the role than to >>>> define “client” as meaning something completely >>>> different. We did this in going from OAuth 1 to >>>> OAuth 2 already, moving from the >>>> even-more-confusing “consumer” to “client”, but >>>> OAuth 2 doesn’t use the term “consumer” at all, nor >>>> does it use “server” on its own but instead always >>>> qualifies it with “Authorization Server” and >>>> “Resource Server”. >>>> >>>> GNAP can do something similar, in my opinion. But >>>> what we can’t do is ignore the fact that GNAP is >>>> going to be coming up in a world that is already >>>> permeated  by OAuth 2 and its terminology. We don’t >>>> have a blank slate to work with, but neither are we >>>> bound to use the same terms and constructs as >>>> before. It’s going to be a delicate balance! >>>> >>>>  — Justin >>>> >>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>>>> > wrote: >>>>> >>>>> I think that is fundamentally part of the question: >>>>> >>>>> We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to >>>>> OAuth 2.0, and reusing terms >>>>> from OAuth 2.0 but with different definitions >>>>> may lead to unnecessary >>>>> confusion >>>>> >>>>> >>>>> If we say that this document assumes OAuth2.0 >>>>> terminology, then we should not change the >>>>> meanings of any definition. If we are saying this >>>>> supersedes or replaces what OAuth 2.0 creates, >>>>> then we should pick the best word for the job and >>>>> ignore conflicting meanings from OAuth 2.0. I have >>>>> a lot of first hand experience of industries >>>>> "ruining words", and attempting to side-step the >>>>> problem rather than redefining the word just >>>>> confuses everyone as everyone forgets the original >>>>> meaning as new documents come out, but the >>>>> confusion with the use of a non-obvious word >>>>> continues. >>>>> >>>>> Food for thought. >>>>> - Warren >>>>> >>>>> >>>>> Warren Parad >>>>> Founder, CTO >>>>> >>>>> Secure your user data and complete your >>>>> authorization architecture. Implement Authress >>>>> . >>>>> >>>>> >>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>>> > wrote: >>>>> >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, >>>>> Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a >>>>> response similar to the one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there’s still a problem with the >>>>> terminology in use here. What >>>>> > > you describe as RS2, which might in fact >>>>> be an RS unto itself, is a >>>>> > > “Client” in OAuth parlance because it is >>>>> /a client of RS1/. What you >>>>> > > call a “client” has no analogue in the >>>>> OAuth world, but it is not at >>>>> > > all the same as an OAuth client. I >>>>> appreciate your mapping of the >>>>> > > entities below, but it makes it difficult >>>>> to hold a discussion if we >>>>> > > aren’t using the same terms. >>>>> > > >>>>> > > The good news is that this isn’t OAuth, >>>>> and as a new WG we can define >>>>> > > our own terms. The bad news is that this >>>>> is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn’t just re-use existing >>>>> terms with new definitions, >>>>> > > but we’ve got a chance to be more precise >>>>> with how we define things. >>>>> > >>>>> > In the ISO context, each document must >>>>> define its own terminology. The >>>>> > boiler plate for RFCs does not mandate a >>>>> terminology or definitions section >>>>> > but does not prevent it either. The >>>>> vocabulary is limited and as long as >>>>> > we clearly define what our terms are >>>>> meaning, we can re-use a term already >>>>> > used in another RFC. This is also the ISO >>>>> approach. >>>>> >>>>> Just because we can do something does not >>>>> necessarily mean that it is a >>>>> good idea to do so.  We are clear that we are >>>>> producing a protocol that is >>>>> conceptually (if not more strongly) related to >>>>> OAuth 2.0, and reusing terms >>>>> from OAuth 2.0 but with different definitions >>>>> may lead to unnecessary >>>>> confusion.  If I understand correctly, a >>>>> similar reasoning prompted Dick to >>>>> use the term "GS" in XAuth, picking a name >>>>> that was not already used in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> 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/ >>> >> > --------------278383E0687200691EF3EB4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Justin,

Denis,

This isn’t mandated, this is one optional flow for the cases where the RS :wants: to talk to the AS.

It is good to know. But what will be the rational(s) for it ? Token introspection ?
If this is the single case, since token transparency is needed for privacy reasons, it is doubtful that it would still be needed.

If flows can be made simpler, let us make them simpler.

Denis


 — Justin

On Aug 12, 2020, at 12:02 PM, Denis <denis.ietf@free.fr> wrote:

Justin,

A soon as the RS needs to talk to the GS (step 2a) , it is a "Big Brother by Design" architecture.
Do you want to mandate it ?

Denis

+1 to this. I think that the core protocol needs to be designed to allow this kind of action, but I also think it is possible that the details of this could end up in an extension to the main document. I’ve put a flag in the ground for this in XYZ in sections 10.3 and 10.4, which is adapted from UMA2’s distributed authorization protocol:


The important detail here, in XYZ’s design, is that the RS has a clear way to communicate to the client what will be needed to fulfill the request, and the client/orchestrator/whatever has a clear way to incorporate that into the main protocol. The details of (2) using the XYZ pattern are:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |----------->|       |                |
  |                       |            |       |                |
  |                       |            |(2a) Register resource set
  |                       |            |------>|                |
  |                       |            |       |                |
  |                       |            |(2b) Return resource reference handle
  |                       |            |<------|                |
  |                       |            |       |                |
  |                       |(2c) Return AS URL and resource reference handle
  |                       |<-----------|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge, include resource handle)
  |                       |------------------->|                |


Note that the client can ALSO request additional resources on top of what the RS returned in (2b), since this is passed simply as one element of the array. 

 — Justin

On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <fpo@adorsys.de> wrote:

Hello Dick,

On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (was User). So the UML participant refers to the role "Requestor"


I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol. If the "Orchestrator/Negotiator/Client" can translate the service request into a resource request, then there will be no need to invoke (2).

When we move beyond identity management, cases become complex and it makes sense to explicitly display this possibility in the protocol flow.

In some open banking designs, 
- the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2).
- the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

/Francis





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

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

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
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




--------------278383E0687200691EF3EB4C-- From nobody Thu Aug 13 06:55:19 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 8C8C63A0C4C for ; Thu, 13 Aug 2020 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 GGRvCxugOoyd for ; Thu, 13 Aug 2020 06:55:14 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 7231B3A0C4A for ; Thu, 13 Aug 2020 06:55:14 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id h19so6254594ljg.13 for ; Thu, 13 Aug 2020 06:55:14 -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=+LgnCw23MAmh8VwZx2MpLPIozXgyYh0EvHVz4ePbnf8=; b=RIjbL68rH7Os0hzi7MhnriIHhu2A9+iJtawkQSQoBfSM084TdmkLoPjnUJh/+SPR5r 4xTgR654zs3zQy4waGmB9lA38vV4cGNfwetblhhVseKD2mPyTAwt6uR2Mvbe/uEgvidA 7RhkcDHZRLdV3nczPWNbV+FmDA5mrgbfNrM084Z1qV+EWzwtYMLOubjM6aA4MtOHB5wp MMqvI7zP8RuB+rMR8CGn7qpQm34LTPF6TVv6tZqKUXYXpeYDq77M4LM5c06u1jilGJw5 ydCEYZyzY+neSdKvDzR94K17ce8uRukn+X182gni1VMnXIxRWO9yi0h3ebU5ok5I305h FXjw== 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=+LgnCw23MAmh8VwZx2MpLPIozXgyYh0EvHVz4ePbnf8=; b=Rq+YvOvFTLZFClO6BOSuWvud5aMzn3UQtDJFG6HrsNQ6hEf7CSH++Ti+tEvx8OfKsN 4Jmf33BP67kHAGi1TFkawrX2X1tIao/0oqEOp1NwKdGf5kknrpJiODEwdBv9zAk+G6qW hvMZ02flmnF4aYNdzVlA0KTYW4j4aBoD8PnYINtWFGK2IdhXPbn5kEJ8GW2C4KccDTNh HHRddneIW4ziGVQBE/8Y/0StqhvtGpI9DksjAi6BXHVmCD3Goz5E4YASk5kzjrUVwijf qGLZLZBcQ3G65EUIYA8X5w/i5phWmDlufbay+NSYYEwhdLJckF326cRMuD9Tbs5t6EVV mT/Q== X-Gm-Message-State: AOAM532i8PPgB/5yRpK1qhjzds3gyiO0pCb4+3nJNBtiG9Hne2Sy7Eqd VSBamxyJUWd0wmPwBg4GSmg6RxqhJg3S9yzHo+s= X-Google-Smtp-Source: ABdhPJxnthY/inqQY5kCxJCM6TtLfgEbiCJDczPH9mn9LTcvUfgbTSulHYfDzvQXULZL34olc5V0NmRsJFBMSW2R7Io= X-Received: by 2002:a2e:865a:: with SMTP id i26mr1999352ljj.246.1597326912179; Thu, 13 Aug 2020 06:55:12 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> In-Reply-To: <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> From: Dick Hardt Date: Thu, 13 Aug 2020 06:54:59 -0700 Message-ID: To: Denis Cc: Benjamin Kaduk , Francis Pouatcha , Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000030d1c605acc2a7d3" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 13:55:18 -0000 --00000000000030d1c605acc2a7d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Client is not a person, it is software created by a developer. The developer of the client is going to read the documentation for the RS to program the Client. On Thu, Aug 13, 2020 at 6:47 AM Denis wrote: > > > > > > > > > > > Dick, > > > > > > > > I first jump on the > > following exchanges: > > > > > > > [Dick] Most deployments today accomplish > > (2) by the developer reading RS documentation. I'm in favor > > of showing that step in an abstract diagram. > > > [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag > > f=C3=B6rst=C3=A5r inte svenska. Jeg forst=C3=A5r ikke norsk. > > > One of the goals is for any Client to access any > > RS without the need to read any documentation. > > > [Dick]That is > > impractical. Most RSes today have resource specific APIs. > > The Client is either reading a standard API doc, or the > > resource specific API doc. > > > > > > > > > I am not so sure > > that it is impractical. > > > > > > > > In 2012, Geert > > Jansen considered the possibility for complete auto-discovery > > by the API user, so that the API can be used by a human with a > > web browser, > > > without any reference to external documentation. See the "Form > > Definition Language" in : > > https://restful-api-design.readthedocs.io/en/latest/forms.html > > > > > > > > > In his view, forms > > need to specify three pieces of information: > > > > > 1. How to contact the target > > and format the input. > > > 2. A list of all available input fields. > > > 3. A list of constraints with which the input fields must > > comply. > > > > > Hence, > > in his view, the > > form consists of 3 parts: form metadata, field definitions, > > and constraints. > > > > > > > > What do you think ? > > > > > > > > > > > > > > > The second point on > > which I would like to insist is about the use of a "dialog > > box" for user interaction. This wording is used in RFC 6973. > > > > > > > > In OAuth 2.0, the user > > consent is performed by the AS using an authorize endpoint > > where the user consent is solicited and captured. > > > > > > > > Since a user, with no > > prior experience, shall first connect to a RS to perform an > > operation, the user consent > > shall be performed by the RS, > > > instead of the > > AS. This means that we > > should define a "consent" endpoint at the RS. > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > comments inline ... > > > > > > > > On Wed, Aug 12, 2020 at 7:14 > > AM Denis wrote: > > > > > >> >> >> >> Hi Dick, >> >> >> >> >> >> >> >> >> >> >> >> Hi Francis, responses inline ... >> >> >> >> >> >> >> >> On Tue, Aug 11, >> >> 2020 at 3:37 PM Francis Pouatcha >> >> wrote: >> >> >> >> >> >>> >>> >>> >>> Hello Dick, >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug >>> >>> 11, 2020 at 6:22 PM Dick Hardt >>> >>> wrote: >>> >>> >>> >>> >>> >>>> >>>> Hi Francis >>>> >>>> >>>> >>>> >>>> >>>> >>>> The user is an entity, not a role in >>>> >>>> the protocol in how I am defining roles, >>>> >>>> so steps (1) and (7) are confusing to me >>>> >>>> on what is happening. >>>> >>>> >>>> >>>> >>>> >>> >>> "Requestor" is the role (*was* >>> >>> User). So the UML participant refers to the >>> >>> role "Requestor" >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> I still don't understand what is happening in >> >> (1) and (7) >> >> >> >> >> >> >> >> >> >> >> > > > > > > > Would you provide more explanation? > > > > > > > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I also think that (2) could be an >>>> >>>> extension to GNAP, rather than part of >>>> >>>> the core protocol. >>>> >>>> >>>> >>>> >>>> >>> >>> If you make it an extension, you hide. It >>> >>> shall rather be an optional, integral part >>> >>> of the protocol. >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> Most deployments today accomplish (2) by the >> >> developer reading RS documentation. I'm in favor >> >> of showing that step in an abstract diagram. >> >> >> >> >> >> >> >> >> [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag >> f=C3=B6rst=C3=A5r inte svenska. Jeg >> >> forst=C3=A5r ikke norsk. >> >> >> One of the goals is for any >> >> Client to access any RS without the need >> >> to read any documentation. >> >> >> >> >> > > > > > > > That is impractical. Most RSes today have resource > > specific APIs. The Client is either reading a standard API > > doc, or the resource specific API doc. > > > > > > >> >> >> >> >> >> >> >> >> >> But it is not clear to me what the requirements >> >> for (2), and they may vary radically across use >> >> cases, so putting it in the core document seems to >> >> be getting ahead of ourselves. >> >> >> >> >> >> >> >> >> [Denis] I can >> >> only reinsist on earlier explanations given about >> >> the Client-server use cases built along "Privacy by >> >> Design" since they are fundamental. >> >> >> >> >> > > I agree with the principle of "Privacy by Design". There > > are LOTS of details in how to do what you outline below, and > > I expect they will be radically different across use cases, > > which is why I don't think it fits into the core document, > > but I do agree with calling it out in the abstract. When I > > publish an updated draft, let me know what you think then. > > > > > > > > > > > >> >> >> >> >> >> >> >> >> >> >> Taking into >> >> consideration both the "data minimization" >> >> principle and the "user participation" principle >> >> when a user first authenticates to a RS leads to >> >> the following: >> >> >> >> >> >> >> >> >> 1) When >> >> accessing a RS for the first time, the user should >> >> be informed of the authentication means proposed >> >> by the RS. The user should be able to use a dialog >> >> box >> >> >> where some choices are presented by the RS. The >> >> user should be able to locally make his own >> >> choices and to indicate his consent to its Client. >> >> >> 2) When a user chooses to perform one >> >> operation on a RS, the RS should limit the data to >> >> be collected from the user to only what is >> >> strictly necessary >> >> >> to perform that operation. That data consists of >> >> specific types of attributes that need to be >> >> guaranteed by one or more ASs. The user should be >> >> able >> >> >> to use a dialog box where some ASs choices are >> >> proposed by the RS. The user should be able to >> >> locally make his own choices and to indicate >> >> >> his consent to its Client. >> >> >> >> >> >> >> >> >> It is >> >> important to notice that the choices that will be >> >> proposed to a user may depend upon previous >> >> personal information voluntarily released by that >> >> user. >> >> >> This means >> >> that the choices proposed by the RS may be >> >> tailored for the user. Furthermore, the proposed >> >> choices may only be disclosed to already >> >> authenticated users. >> >> >> >> >> Denis >> >> >> >> >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> In some open banking designs, >>> >>> >>> - the "Orchestrator/Negotiator/Client" >>> >>> will not know the AS to talk to unless the >>> >>> call (2). >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> Have you put these use cases in the wiki? >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> - the request (2) might result in an >>> >>> exemption, meaning no need for further >>> >>> authorization, allowing to skip (3, 4, 5) >>> >>> and even (6). >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> Agreed. >> >> >> >> >> >> >> >> >> =E1=90=A7 >> >> >> >> >> >> >> >> >> >> >> >> > > > > > > =E1=90=A7 > > > > > > > > > > > > > > -- > > TXAuth mailing list > > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > --00000000000030d1c605acc2a7d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The Client is not a person, it is software created b= y a developer. The developer of the client is going to read the documentati= on for the RS to program the Client.

On Thu, Aug 13, 2020 at 6:47= AM Denis <denis.ietf@free.fr&= gt; wrote:









Dick,





<= br>
I first jump on the

following exchanges:
=





[Dick] Most deploym= ents today accomplish

(2) by the developer reading RS do= cumentation. I'm in favor

of showing that step in an= abstract diagram.


[Denis] Really by reading RS do= cumentation ? Non capisco l'italiano. Jag

f=C3=B6rst=C3= =A5r inte svenska. Jeg forst=C3=A5r ikke norsk.


= One of the goals is for any Client to access any

= RS without the need to read any documentation.



[Dick]That is

= impractical. Most RSes today have resource specific APIs.

= The Client is either reading a standard API doc, or the

= resource specific API doc.



=




I am not so sure

= that it is impractical.







In 2012, Geert

Jansen considered the = possibility for complete auto-discovery

by the API user, s= o that the API can be used by a human with a

web browser, =


without any reference to external documentation. See = the "Form

Definition Language" in :

https://restful-api-design.readthed= ocs.io/en/latest/forms.html



=





In his view, forms

= need to specify three pieces of information:




1.=C2=A0=C2=A0=C2=A0 How to contact the target

= and format the input.


2.=C2=A0=C2=A0=C2= =A0 A list of all available input fields.


3.=C2=A0= =C2=A0=C2=A0 A list of constraints with which the input fields must

= comply.




= Hence,

= in his view, the

form consists of 3 parts: form me= tadata, field definitions,

and constraints.







What do you think ?

<= br>





<= br>




The second point on

= which I would like to insist is about the use of a "dialog

= box" for user interaction. This wording is used in RFC 6973= .







=
In OAuth 2.0, = the user

consent is performed by the AS using an authori= ze endpoint

where the user consent is solicited and capt= ured.






=
Since= a user, with no

prior experience, shall first connect t= o a RS to perform an

operation, the user consent

shall be p= erformed by the RS,


<= font face=3D"Arial" style=3D"font-family:Arial;color:rgb(0,0,0)">instead of the

AS. <= /span>This means that we

should define a "co= nsent" endpoint at the RS.





Denis










<= br>











comments inline ...=C2=A0





=


On Wed, Aug 12, 2020 at 7:14

AM Denis <denis.ietf@free.fr&g= t; wrote:







Hi Dick,


=









=
Hi Francis, responses inline ...=C2=A0


=



On Tue, Aug 11,=

2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de>

= wrote:




=




Hello Dick,
=






On Tue, Aug

11, 2020 at= 6:22 PM Dick Hardt <dick.hardt@gmail.com>

wrot= e:




=


= Hi Francis




=


The us= er is an entity, not a role in

the p= rotocol in how I am defining roles,

= so steps (1) and (7) are confusing to me

= on what is happening.


<= br>


=
"Requestor" is the role (was

= User). So the UML participant refers=C2=A0to the

= role "Requestor"


=




=





=


I still don't unders= tand what is happening in

(1) and (7)





=











= Would you provide more explanation?


=C2=A0
<= br>




=




=


=

=C2=A0






=







=




=


=





=
I also think that (2) could be an

= extension to GNAP, rather than part of

= the core protocol.


=




=
If you make it an extension, you hide. It
shall rather be an optional, integral part
=
of the protocol.


=




=





=


Most deployments today acc= omplish (2) by the

developer reading RS docume= ntation. I'm in favor

of showing that step= in an abstract diagram.




=




=

[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag f=C3=B6rst=C3=A5r inte = svenska. Jeg
<= br> forst=C3=A5r ikke norsk.



One of the goals is for a= ny

Client to access any RS without the= need

to read any documentation.









<= /div>

That is impractical. Most RSes today have resou= rce

specific APIs. The Client is either reading a standa= rd API

doc, or the resource specific API doc.

<= br>
=C2=A0




=




=




But it is not clear to me what the = requirements

for (2), and they may vary radica= lly across use

cases, so putting it in the cor= e document seems to

be getting ahead of oursel= ves.







[Denis] I can

only reinsist on earlier= explanations given about

the Client-server use = cases built along "Privacy by

Design" = since they are fundamental.






I agree with the princip= le of "Privacy by Design". There

are LOTS of d= etails in how to do what you outline below, and

I expect= they will be radically different across use cases,

whic= h is why I don't think it fits into the core document,

= but I do agree with calling it out in the abstract. When I

= publish an updated draft, let me know what you think then.

<= br>





=C2=A0=






=




=





Taking into

cons= ideration both the "data minimization"

= principle and the "user participation" principle

= when a user first authenticates to a RS leads to

= the following:









1)= When

accessing a RS for the first time, the u= ser should

be informed of the authentication m= eans proposed

by the RS. The user should be ab= le to use a dialog

box


= where some choices are presented by the RS. The

= user should be able to locally make his own

= choices and to indicate his consent to its Client.=



2) When a user chooses to perform one

= operation on a RS, the RS should limit the data to

= be collected from the user to only what is

= strictly necessary


to perform tha= t operation. That data consists of

specific ty= pes of attributes that need to be

guaranteed b= y one or more ASs. The user should be

able

to use a dialog box where some ASs choices a= re

proposed by the RS. The user should be able= to

locally make his own choices and to indica= te


his consent to its Client.









=

It is

= important to notice that the choices that will be

= proposed to a user may depend upon previous

= personal information voluntarily released by that

= user.


This means

that the choices propo= sed by the RS may be

tailored for the user. Fu= rthermore, the proposed

choices may only be di= sclosed to already

authenticated users.=





Denis







=


= =C2=A0




=




In some open banking de= signs,=C2=A0


- the "Orches= trator/Negotiator/Client"

will not = know the AS to talk to unless the

call (= 2).




=




=





Have you put these use cases in the wiki?


=
=C2=A0




=




- the request (= 2) might result in an

exemption, meaning= no need for further

authorization, allo= wing to skip (3, 4, 5)

and even (6).







=




Agre= ed.







=
3D""=E1=90=A7


=






=




=



3D""=E1=90=A7








=




--

TXAuth mailing list

TXAuth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth

--00000000000030d1c605acc2a7d3-- From nobody Thu Aug 13 06:55:27 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 BEE393A0C5F for ; Thu, 13 Aug 2020 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4L67ZPW4Zy43 for ; Thu, 13 Aug 2020 06:55:20 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B083A0C4D for ; Thu, 13 Aug 2020 06:55:19 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id F1vH230082bcEcA031vHbM; Thu, 13 Aug 2020 15:55:17 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 15:55:17 +0200 X-ME-IP: 90.79.51.120 To: Fabien Imbault , Dave Tonge Cc: Justin Richer , Dick Hardt , Mike Jones , Tom Jones , Francis Pouatcha , Benjamin Kaduk , "txauth@ietf.org" References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> From: Denis Message-ID: <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> Date: Thu, 13 Aug 2020 15:55:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2AA6ADA604B763C657664B38" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 13 Aug 2020 13:55:27 -0000 This is a multi-part message in MIME format. --------------2AA6ADA604B763C657664B38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Fabien, IMHO, nothing is wrong with keeping "Client" since it has a wide spread usage ... but only as long as we can agree on a short and a clear definition for it. I can provide the beginning of such a definition: " application ..." If someone could go a little bit further, this would help. :-) A similar argumentation for GS.  It could be used but only as long as we can agree on a short and a clear definition for it. Any proposal ? Denis > Hi, > > Nothing inherently wrong with Client/AS, which has worked for years in > the context of OAuth2. The question is to know whether we can build > the new protocol with the same concepts and deal with their known > limitations, or if we're better off with more adapted concepts less > prone to misunderstandings. > > Verb vs Noun: > Problem is that the grant (noun) can only be understood if there is a > grant(verb), i.e. some action that grants something. > The grant (noun) definition directly derives from the verb : > "something granted ..." > > I personally have no issue even with the fairly convoluted "The Grant > Server issues a grant to the Grant Client representing access that has > been granted" (except perhaps from the word Client, but that's a > different issue). > By the way, grant is nothing new, it's used extensively in OAuth2 as > "grant types" (whatever that means). > > Dick summarized well the reasons why he uses GS instead of AS : > 1) "grant" is in the working group name (a weaker reason, but still > has been approved). Question: would our reasoning if the protocol > ended up being called OAuth3? > 2) grant = larger in scope than AS (not only authorization), as it at > least includes idclaims + other use cases like payment (?) - no > consensus, see difference in appreciation between Justin and Dick > > As for "Client", if most people think it is problematic, it seems a > good reason to change if we find a better alternative. > Quoting Dick again: "The confusion in my experience usually stems from > people working with software that is acting in multiple roles. IE, the > software that is acting as a client in once context, is also acting as > an RS in other contexts, or even acting as an AS. The other confusion > is that people view clients as being the software the user is using -- > although it may not be acting as a client in the oauth context." and > later "I do agree that it is not the best term in GNAP. Primarily > because GNAP is a combination of the client from OAuth 2, and the > relying party from OIDC." > > So far there's no consensus however, recent tries: Initiating > Application (Denis), Orchestrator (Francis). > > Cheers > Fabien > > > > > On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge > wrote: > > I would be against using "grant" as both a verb and a noun and > stick purely with one or the other. (In the charter the only use > of "grant" is in the verb: "granted"). > > Using it as both a verb and a noun will be confusing and less > accessible. > > I think it will be confusing to say "The Grant Server issues a > grant to the Grant Client representing access that has been granted" > > Whether the access takes place via a token being returned and used > at a resource server, or "claims" that are directly returned from > the "Grant Server" I think should be largely irrelevant when it > comes to the naming of the roles. > > In almost all use cases that I have seen the "Grant Server" is > making a policy based decision "to grant" access to requested > resource(s). To me, that is the fundamental operation happening. I > think nearly all use cases can be applied to that, e.g. the GS > grants access to >  - identity attributes for the end user >  - verify an identity attribute (e.g. that user is over 18) >  - all users photos at resource server X >  - a single photo with id 12345 at resource server Y >  - resource of type X at any resource server that trusts the Grant > Server >  - call a payment API with specific properties (e.g. amount < 5) >  - call a file storage API >  - call a "contract signing" API with specific properties (e.g. > contract hash of xxx,) > While "client" is problematic, it does now have wide spread usage, > so perhaps we are stuck with it. > However I agree with Justin and think "Grant Client" makes things > more confusing. > > What is wrong with keeping "Client" and "Authorization Server"? > > Dave > > > > > Moneyhub Enterprise is a trading style of Moneyhub Financial > Technology Limited which is authorised and regulated by the > Financial Conduct Authority ("FCA"). Moneyhub Financial Technology > is entered on the Financial Services Register (FRN 809360) at > https://register.fca.org.uk/. Moneyhub Financial Technology is > registered in England & Wales, company registration number > 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub > Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this > email or of any information in it other than by the addressee is > unauthorised and unlawful. Whilst reasonable efforts are made to > ensure that any attachments are virus-free, it is the recipient's > sole responsibility to scan all attachments for viruses. All calls > and emails to and from this company may be monitored and recorded > for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those > of the author and do not necessarily represent the opinions of > Moneyhub Financial Technology Limited or of any other group company. > > --------------2AA6ADA604B763C657664B38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Fabien,

IMHO, nothing is wrong with keeping "Client" since it has a wide spread usage
... but only as long as we can agree on a short and a clear definition for it.
I can provide the beginning of such a definition: " application ..."

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.  It could be used but only as long as we can agree on a short and a clear definition for it.
Any proposal ?

Denis

Hi,

Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings.

Verb vs Noun:
Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something. 
The grant (noun) definition directly derives from the verb : "something granted ..."

I personally have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perhaps from the word Client, but that's a different issue).
By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types" (whatever that means). 

Dick summarized well the reasons why he uses GS instead of AS : 
1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
2) grant = larger in scope than AS (not only authorization), as it at least includes idclaims + other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick

As for "Client", if most people think it is problematic, it seems a good reason to change if we find a better alternative. 
Quoting Dick again: "The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context." and later "I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC."

So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis). 

Cheers
Fabien




On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I would be against using "grant" as both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant" is in the verb: "granted").

Using it as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted"

Whether the access takes place via a token being returned and used at a resource server, or "claims" that are directly returned from the "Grant Server" I think should be largely irrelevant when it comes to the naming of the roles.

In almost all use cases that I have seen the "Grant Server" is making a policy based decision "to grant" access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
 - identity attributes for the end user
 - verify an identity attribute (e.g. that user is over 18)
 - all users photos at resource server X
 - a single photo with id 12345 at resource server Y
 - resource of type X at any resource server that trusts the Grant Server
 - call a payment API with specific properties (e.g. amount < 5)
 - call a file storage API
 - call a "contract signing" API with specific properties (e.g. contract hash of xxx,)
 
While "client" is problematic, it does now have wide spread usage, so perhaps we are stuck with it. 
However I agree with Justin and think "Grant Client" makes things more confusing.

What is wrong with keeping "Client" and "Authorization Server"? 

Dave




Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.



--------------2AA6ADA604B763C657664B38-- From nobody Thu Aug 13 07:04:28 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 D2D1E3A0C54 for ; Thu, 13 Aug 2020 07:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 fTfCj36ks6sa for ; Thu, 13 Aug 2020 07:04:23 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACED83A0C53 for ; Thu, 13 Aug 2020 07:04:22 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id F24L2300C2bcEcA0324LK1; Thu, 13 Aug 2020 16:04:21 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 16:04:21 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: Benjamin Kaduk , Francis Pouatcha , Justin Richer , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> From: Denis Message-ID: Date: Thu, 13 Aug 2020 16:04:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A1A8E43250851C69853573F2" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 14:04:26 -0000 This is a multi-part message in MIME format. --------------A1A8E43250851C69853573F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dick, A web browser is not a person. Denis PS1. You didn't reply to the second point of my email about a "consent" endpoint at the RS. PS2. It would be better that you wait until you can use a real laptop to respond and that you re-use the original message,          because the message you sent back is almost unreadable. > The Client is not a person, it is software created by a developer. The > developer of the client is going to read the documentation for the RS > to program the Client. > > On Thu, Aug 13, 2020 at 6:47 AM Denis > wrote: > > > > > > > > > > > > Dick, > > > > > > > > I first jump on the > > following exchanges: > > > > > > > [Dick] Most deployments today accomplish > > (2) by the developer reading RS documentation. I'm in favor > > of showing that step in an abstract diagram. > > > [Denis] Really by reading RS documentation ? Non capisco > l'italiano. Jag > > förstår inte svenska. Jeg forstår ikke norsk. > > > One of the goals is for any Client to access any > > RS without the need to read any documentation. > > > > [Dick]That is > > impractical. Most RSes today have resource specific APIs. > > The Client is either reading a standard API doc, or the > > resource specific API doc. > > > > > > > > > I am not so sure > > that it is impractical. > > > > > > > > In 2012, Geert > > Jansen considered the possibility for complete auto-discovery > > by the API user, so that the API can be used by a human with a > > web browser, > > > without any reference to external documentation. See the "Form > > Definition Language" in : > > https://restful-api-design.readthedocs.io/en/latest/forms.html > > > > > > > > > In his view, forms > > need to specify three pieces of information: > > > > > 1.    How to contact the target > > and format the input. > > > 2.    A list of all available input fields. > > > 3.    A list of constraints with which the input fields must > > comply. > > > > > Hence, > > in his view, the > > form consists of 3 parts: form metadata, field definitions, > > and constraints. > > > > > > > > What do you think ? > > > > > > > > > > > > > > > The second point on > > which I would like to insist is about the use of a "dialog > > box" for user interaction. This wording is used in RFC 6973. > > > > > > > > In OAuth 2.0, the user > > consent is performed by the AS using an authorize endpoint > > where the user consent is solicited and captured. > > > > > > > > Since a user, with no > > prior experience, shall first connect to a RS to perform an > > operation, the user consent > > shall be performed by the RS, > > > instead of the > > AS. This means that we > > should define a "consent" endpoint at the RS. > > > > > > > > Denis > > > > > > > > > > > > > > > > > > >> >> >> >> >> >> >> comments inline ... >> >> >> >> >> >> >> >> On Wed, Aug 12, 2020 at 7:14 >> >> AM Denis > wrote: >> >> >> >> >> >> >> >> >> Hi Dick, >> >> >> >> >> >> >> >>> >>> >>> >>> >>> Hi Francis, responses inline ... >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 11, >>> >>> 2020 at 3:37 PM Francis Pouatcha >> > >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> Hello Dick, >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug >>> >>> 11, 2020 at 6:22 PM Dick Hardt >> > >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> Hi Francis >>> >>> >>> >>> >>> >>> >>> The user is an entity, not a role in >>> >>> the protocol in how I am defining roles, >>> >>> so steps (1) and (7) are confusing to me >>> >>> on what is happening. >>> >>> >>> >>> >>> >>> >>> "Requestor" is the role (*was* >>> >>> User). So the UML participant refers to the >>> >>> role "Requestor" >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I still don't understand what is happening in >>> >>> (1) and (7) >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> >> >> >> >> Would you provide more explanation? >> >> >> >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I also think that (2) could be an >>> >>> extension to GNAP, rather than part of >>> >>> the core protocol. >>> >>> >>> >>> >>> >>> >>> If you make it an extension, you hide. It >>> >>> shall rather be an optional, integral part >>> >>> of the protocol. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Most deployments today accomplish (2) by the >>> >>> developer reading RS documentation. I'm in favor >>> >>> of showing that step in an abstract diagram. >>> >>> >>> >>> >>> >>> >> >> >> [Denis] Really by reading RS documentation ? Non capisco >> l'italiano. Jag förstår inte svenska. Jeg >> >> forstår ikke norsk. >> >> >> >> One of the goals is for any >> >> Client to access any RS without the need >> >> to read any documentation. >> >> >> >> >> >> >> >> >> >> >> >> >> That is impractical. Most RSes today have resource >> >> specific APIs. The Client is either reading a standard API >> >> doc, or the resource specific API doc. >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> But it is not clear to me what the requirements >>> >>> for (2), and they may vary radically across use >>> >>> cases, so putting it in the core document seems to >>> >>> be getting ahead of ourselves. >>> >>> >>> >>> >>> >>> >> >> >> [Denis] I can >> >> only reinsist on earlier explanations given about >> >> the Client-server use cases built along "Privacy by >> >> Design" since they are fundamental. >> >> >> >> >> >> >> >> I agree with the principle of "Privacy by Design". There >> >> are LOTS of details in how to do what you outline below, and >> >> I expect they will be radically different across use cases, >> >> which is why I don't think it fits into the core document, >> >> but I do agree with calling it out in the abstract. When I >> >> publish an updated draft, let me know what you think then. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Taking into >> >> consideration both the "data minimization" >> >> principle and the "user participation" principle >> >> when a user first authenticates to a RS leads to >> >> the following: >> >> >> >> >> >> >> >> >> >> 1) When >> >> accessing a RS for the first time, the user should >> >> be informed of the authentication means proposed >> >> by the RS. The user should be able to use a dialog >> >> box >> >> >> where some choices are presented by the RS. The >> >> user should be able to locally make his own >> >> choices and to indicate his consent to its Client. >> >> >> >> 2) When a user chooses to perform one >> >> operation on a RS, the RS should limit the data to >> >> be collected from the user to only what is >> >> strictly necessary >> >> >> to perform that operation. That data consists of >> >> specific types of attributes that need to be >> >> guaranteed by one or more ASs. The user should be >> >> able >> >> >> to use a dialog box where some ASs choices are >> >> proposed by the RS. The user should be able to >> >> locally make his own choices and to indicate >> >> >> his consent to its Client. >> >> >> >> >> >> >> >> >> >> It is >> >> important to notice that the choices that will be >> >> proposed to a user may depend upon previous >> >> personal information voluntarily released by that >> >> user. >> >> >> This means >> >> that the choices proposed by the RS may be >> >> tailored for the user. Furthermore, the proposed >> >> choices may only be disclosed to already >> >> authenticated users. >> >> >> >> >> >> Denis >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> In some open banking designs, >>> >>> >>> - the "Orchestrator/Negotiator/Client" >>> >>> will not know the AS to talk to unless the >>> >>> call (2). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Have you put these use cases in the wiki? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> - the request (2) might result in an >>> >>> exemption, meaning no need for further >>> >>> authorization, allowing to skip (3, 4, 5) >>> >>> and even (6). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Agreed. >>> >>> >>> >>> >>> >>> >>> >>> >>> ᐧ >>> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ᐧ >> >> > > > > > > > > > > > > -- > > TXAuth mailing list > > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > --------------A1A8E43250851C69853573F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dick,

A web browser is not a person.

Denis

PS1. You didn't reply to the second point of my email about a "consent" endpoint at the RS.

PS2. It would be better that you wait until you can use a real laptop to respond and that you re-use the original message,
         because the message you sent back is almost unreadable.

The Client is not a person, it is software created by a developer. The developer of the client is going to read the documentation for the RS to program the Client.

On Thu, Aug 13, 2020 at 6:47 AM Denis <denis.ietf@free.fr> wrote:










Dick,







I first jump on the

following exchanges:






[Dick] Most deployments today accomplish

(2) by the developer reading RS documentation. I'm in favor

of showing that step in an abstract diagram.


[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag

förstår inte svenska. Jeg forstår ikke norsk.


One of the goals is for any Client to access any

RS without the need to read any documentation.



[Dick]That is

impractical. Most RSes today have resource specific APIs.

The Client is either reading a standard API doc, or the

resource specific API doc.








I am not so sure

that it is impractical.







In 2012, Geert

Jansen considered the possibility for complete auto-discovery

by the API user, so that the API can be used by a human with a

web browser,


without any reference to external documentation. See the "Form

Definition Language" in :

https://restful-api-design.readthedocs.io/en/latest/forms.html








In his view, forms

need to specify three pieces of information:




1.    How to contact the target

and format the input.


2.    A list of all available input fields.


3.    A list of constraints with which the input fields must

comply.




Hence,

in his view, the

form consists of 3 parts: form metadata, field definitions,

and constraints.







What do you think ?














The second point on

which I would like to insist is about the use of a "dialog

box" for user interaction. This wording is used in RFC 6973.







In OAuth 2.0, the user

consent is performed by the AS using an authorize endpoint

where the user consent is solicited and captured.







Since a user, with no

prior experience, shall first connect to a RS to perform an

operation, the user consent

shall be performed by the RS,


instead of the

AS. This means that we

should define a "consent" endpoint at the RS.







Denis
























comments inline ... 







On Wed, Aug 12, 2020 at 7:14

AM Denis <denis.ietf@free.fr> wrote:








Hi Dick,











Hi Francis, responses inline ... 







On Tue, Aug 11,

2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de>

wrote:








Hello Dick,







On Tue, Aug

11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com>

wrote:






Hi Francis






The user is an entity, not a role in

the protocol in how I am defining roles,

so steps (1) and (7) are confusing to me

on what is happening.






"Requestor" is the role (was

User). So the UML participant refers to the

role "Requestor"













I still don't understand what is happening in

(1) and (7)

















Would you provide more explanation?


 














 
























I also think that (2) could be an

extension to GNAP, rather than part of

the core protocol.






If you make it an extension, you hide. It

shall rather be an optional, integral part

of the protocol.













Most deployments today accomplish (2) by the

developer reading RS documentation. I'm in favor

of showing that step in an abstract diagram.








[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag förstår inte svenska. Jeg

forstår ikke norsk.



One of the goals is for any

Client to access any RS without the need

to read any documentation.












That is impractical. Most RSes today have resource

specific APIs. The Client is either reading a standard API

doc, or the resource specific API doc.


 












But it is not clear to me what the requirements

for (2), and they may vary radically across use

cases, so putting it in the core document seems to

be getting ahead of ourselves.








[Denis] I can

only reinsist on earlier explanations given about

the Client-server use cases built along "Privacy by

Design" since they are fundamental.







I agree with the principle of "Privacy by Design". There

are LOTS of details in how to do what you outline below, and

I expect they will be radically different across use cases,

which is why I don't think it fits into the core document,

but I do agree with calling it out in the abstract. When I

publish an updated draft, let me know what you think then.







 













Taking into

consideration both the "data minimization"

principle and the "user participation" principle

when a user first authenticates to a RS leads to

the following:









1) When

accessing a RS for the first time, the user should

be informed of the authentication means proposed

by the RS. The user should be able to use a dialog

box


where some choices are presented by the RS. The

user should be able to locally make his own

choices and to indicate his consent to its Client.



2) When a user chooses to perform one

operation on a RS, the RS should limit the data to

be collected from the user to only what is

strictly necessary


to perform that operation. That data consists of

specific types of attributes that need to be

guaranteed by one or more ASs. The user should be

able


to use a dialog box where some ASs choices are

proposed by the RS. The user should be able to

locally make his own choices and to indicate


his consent to its Client.









It is

important to notice that the choices that will be

proposed to a user may depend upon previous

personal information voluntarily released by that

user.


This means

that the choices proposed by the RS may be

tailored for the user. Furthermore, the proposed

choices may only be disclosed to already

authenticated users.





Denis









 








In some open banking designs, 


- the "Orchestrator/Negotiator/Client"

will not know the AS to talk to unless the

call (2).













Have you put these use cases in the wiki?


 








- the request (2) might result in an

exemption, meaning no need for further

authorization, allowing to skip (3, 4, 5)

and even (6).













Agreed.








ᐧ

















ᐧ













--

TXAuth mailing list

TXAuth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth


--------------A1A8E43250851C69853573F2-- From nobody Thu Aug 13 07:47:06 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 C942D3A0C8F for ; Thu, 13 Aug 2020 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PO8tauugFATS for ; Thu, 13 Aug 2020 07:47:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580E13A0C8E for ; Thu, 13 Aug 2020 07:47:00 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DEktZl014434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 10:46:56 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_333F43BE-9AD2-4847-86EE-2E5746700105" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 10:46:55 -0400 In-Reply-To: <4432c842-ee1c-40bc-1337-0db4cc96dd83@free.fr> Cc: Benjamin Kaduk , "txauth@ietf.org" To: Denis References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <89938F38-6BA2-4D57-88DA-0E022D0DEA98@mit.edu> <417CAA5C-3F64-4284-95C6-CA58E07AF7F0@mit.edu> <4432c842-ee1c-40bc-1337-0db4cc96dd83@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 14:47:05 -0000 --Apple-Mail=_333F43BE-9AD2-4847-86EE-2E5746700105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Different use cases are pulling for =E2=80=9Csimplicity=E2=80=9D in = different directions, and I think that we can have a core protocol that = supports these without getting overly convoluted. At least, that=E2=80=99s= the goal! The rationale for having an RS register in this way is for a scenario = where the AS is the trusted component in the ecosystem. I fully realize = that this is very different from your scenario, where the AS is not = trusted directly by the RS in the same way. Here, the RS wants to = provide a specific runtime reference for what a particular client is = trying to do, independent of any static API definitions for = resources/scopes. In this ecosystem, the AS is trusted to manage and = provision access to all of the RS=E2=80=99s, and the RS=E2=80=99s are = known to the AS ahead of time. Yes, it=E2=80=99s acting as a =E2=80=9Cbig = brother=E2=80=9D as you put it, but that=E2=80=99s the intentional = design =E2=80=94 the RS=E2=80=99s have outsourced portions of their = security and trust to the AS.=20 The inspiration for this is UMA=E2=80=99s federated authorization spec, = which I also helped develop: = https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.= 0.html = This pattern is in use in the wild, but unfortunately limitations in = OAuth 2 make it more separate from the OAuth ecosystem than it really = ought to be. By bringing this idea of the RS and AS having a more loose = runtime association into GNAP, we can solve not only the =E2=80=9Cstrong = AS=E2=80=9D UMA use cases but also the =E2=80=9Cnaive AS=E2=80=9D use = case that you=E2=80=99re bringing. =E2=80=94 Justin > On Aug 13, 2020, at 9:49 AM, Denis wrote: >=20 > Justin, >=20 >> Denis, >>=20 >> This isn=E2=80=99t mandated, this is one optional flow for the cases = where the RS :wants: to talk to the AS.=20 > It is good to know. But what will be the rational(s) for it ? Token = introspection ? > If this is the single case, since token transparency is needed for = privacy reasons, it is doubtful that it would still be needed. >=20 > If flows can be made simpler, let us make them simpler. >=20 > Denis >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Aug 12, 2020, at 12:02 PM, Denis > wrote: >>>=20 >>> Justin, >>>=20 >>> A soon as the RS needs to talk to the GS (step 2a) , it is a "Big = Brother by Design" architecture.=20 >>> Do you want to mandate it ? >>>=20 >>> Denis >>>=20 >>>> +1 to this. I think that the core protocol needs to be designed to = allow this kind of action, but I also think it is possible that the = details of this could end up in an extension to the main document. = I=E2=80=99ve put a flag in the ground for this in XYZ in sections 10.3 = and 10.4, which is adapted from UMA2=E2=80=99s distributed authorization = protocol: >>>>=20 >>>> = https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10= .3 = >>>>=20 >>>> The important detail here, in XYZ=E2=80=99s design, is that the RS = has a clear way to communicate to the client what will be needed to = fulfill the request, and the client/orchestrator/whatever has a clear = way to incorporate that into the main protocol. The details of (2) using = the XYZ pattern are: >>>>=20 >>>> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >>>> | Requestor | | Orchestrator | | | | GS | | Resource = Controller | >>>> | was | | was | | RS | | or | | was = | >>>> | User | | Client | | | | AS | | Resource = Owner | >>>> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >>>> |(1) ServiceRequest | | | | >>>> |---------------------->| | | | >>>> | |(2) ServiceIntent:AuthZChallenge | >>>> | |----------->| | | >>>> | | | | | >>>> | | |(2a) Register resource set >>>> | | |------>| | >>>> | | | | | >>>> | | |(2b) Return resource = reference handle >>>> | | |<------| | >>>> | | | | | >>>> | |(2c) Return AS URL and resource = reference handle >>>> | |<-----------| | | >>>> | | | | | >>>> | |(3) AuthZRequest(AuthZChallenge, include = resource handle) >>>> | |------------------->| | >>>>=20 >>>>=20 >>>> Note that the client can ALSO request additional resources on top = of what the RS returned in (2b), since this is passed simply as one = element of the array.=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha > wrote: >>>>>=20 >>>>> Hello Dick, >>>>>=20 >>>>> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt > wrote: >>>>> Hi Francis >>>>>=20 >>>>> The user is an entity, not a role in the protocol in how I am = defining roles, so steps (1) and (7) are confusing to me on what is = happening. >>>>> "Requestor" is the role (was User). So the UML participant refers = to the role "Requestor" >>>>>=20 >>>>>=20 >>>>> I also think that (2) could be an extension to GNAP, rather than = part of the core protocol. >>>>> If you make it an extension, you hide. It shall rather be an = optional, integral part of the protocol. If the = "Orchestrator/Negotiator/Client" can translate the service request into = a resource request, then there will be no need to invoke (2). >>>>>=20 >>>>> When we move beyond identity management, cases become complex and = it makes sense to explicitly display this possibility in the protocol = flow. >>>>>=20 >>>>> In some open banking designs,=20 >>>>> - the "Orchestrator/Negotiator/Client" will not know the AS to = talk to unless the call (2). >>>>> - the request (2) might result in an exemption, meaning no need = for further authorization, allowing to skip (3, 4, 5) and even (6). >>>>>=20 >>>>> /Francis >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha > wrote: >>>>> In this context, I suggest we pick some words to work with, and = sharpen them as we move on, discover and map new use cases to the = protocol. >>>>>=20 >>>>> In this diagram from the original thread = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ), I replaced the words: >>>>>=20 >>>>> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >>>>> | Requestor | | Orchestrator | | | | GS | | Resource = Controller | >>>>> | was | | was | | RS | | or | | was = | >>>>> | User | | Client | | | | AS | | Resource = Owner | >>>>> +-----------+ +--------------+ +----+ +----+ = +---------------------+ >>>>> |(1) ServiceRequest | | | | >>>>> |---------------------->| | | | >>>>> | |(2) ServiceIntent:AuthZChallenge | >>>>> | |<---------->| | | >>>>> | | | | | >>>>> | |(3) AuthZRequest(AuthZChallenge) | >>>>> | |------------------->| | >>>>> | | | |(4) = ConsentRequest:Grant >>>>> | | | |<-------------->| >>>>> | |(5) GrantAccess(AuthZ) | >>>>> | |<-------------------| | >>>>> | | | | | >>>>> | |(6) = ServiceRequest(AuthZ):ServiceResponse >>>>> | |<---------->| | | >>>>> |(7) ServiceResponse | | | | >>>>> |<----------------------| | | | >>>>> + + + + + >>>>>=20 >>>>> The purpose of the GNAP protocol is to help negotiate access to a = protected resource. It starts with a requestor delegating activity to an = orchestrator. These are all roles, no entities. Let focus on mapping the = use cases to the protocol roles and interactions so wwe can discover = what is missing. >>>>>=20 >>>>> It seems cumbersome to use it in discussions as it is impossible = to give the word "Client" a clear definition. >>>>>=20 >>>>> We can mention in the final document, that the "Orchestrator" (or = whatever word we finally use) plays the same role as the "Client" in = oAuth2. >>>>>=20 >>>>> Best regards. >>>>> /Francis >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt > wrote: >>>>> I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >>>>>=20 >>>>> Given what we have learned, and my own experience explaining what = a Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.=20 >>>>>=20 >>>>> For example, clarifying that a Client is a role an entity plays in = the protocol, and that the same entity may play other roles at other = times, or some other language to help differentiate between "role" and = "entity". >>>>>=20 >>>>> /Dick >>>>> =E1=90=A7 >>>>>=20 >>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > wrote: >>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>>=20 >>>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is ignore the fact that GNAP is going to be coming up in a world = that is already permeated by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad > wrote: >>>>>>=20 >>>>>> I think that is fundamentally part of the question: >>>>>> We are clear that we are producing a protocol that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>>>> confusion >>>>>>=20 >>>>>> If we say that this document assumes OAuth2.0 terminology, then = we should not change the meanings of any definition. If we are saying = this supersedes or replaces what OAuth 2.0 creates, then we should pick = the best word for the job and ignore conflicting meanings from OAuth = 2.0. I have a lot of first hand experience of industries "ruining = words", and attempting to side-step the problem rather than redefining = the word just confuses everyone as everyone forgets the original meaning = as new documents come out, but the confusion with the use of a = non-obvious word continues. >>>>>>=20 >>>>>> Food for thought. >>>>>> - Warren >>>>>>=20 >>>>>>=20 >>>>>> Warren Parad >>>>>> Founder, CTO >>>>>> Secure your user data and complete your authorization = architecture. Implement Authress . >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > wrote: >>>>>> Hi Denis, >>>>>>=20 >>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>> > Hi Justin, >>>>>> >=20 >>>>>> > Since you replied in parallel, I will make a response similar = to the one=20 >>>>>> > I sent to Dick. >>>>>> >=20 >>>>>> > > Hi Denis, >>>>>> > > >>>>>> > > I think there=E2=80=99s still a problem with the terminology = in use here. What=20 >>>>>> > > you describe as RS2, which might in fact be an RS unto = itself, is a=20 >>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you=20 >>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at=20 >>>>>> > > all the same as an OAuth client. I appreciate your mapping of = the=20 >>>>>> > > entities below, but it makes it difficult to hold a = discussion if we=20 >>>>>> > > aren=E2=80=99t using the same terms. >>>>>> > > >>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define=20 >>>>>> > > our own terms. The bad news is that this is really hard to = do. >>>>>> > > >>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,=20 >>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we = define things. >>>>>> >=20 >>>>>> > In the ISO context, each document must define its own = terminology. The=20 >>>>>> > boiler plate for RFCs does not mandate a terminology or = definitions section >>>>>> > but does not prevent it either. The vocabulary is limited and = as long as=20 >>>>>> > we clearly define what our terms are meaning, we can re-use a = term already >>>>>> > used in another RFC. This is also the ISO approach. >>>>>>=20 >>>>>> Just because we can do something does not necessarily mean that = it is a >>>>>> good idea to do so. We are clear that we are producing a = protocol that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and = reusing terms >>>>>> from OAuth 2.0 but with different definitions may lead to = unnecessary >>>>>> confusion. If I understand correctly, a similar reasoning = prompted Dick to >>>>>> use the term "GS" in XAuth, picking a name that was not already = used in >>>>>> OAuth 2.0. >>>>>>=20 >>>>>> -Ben >>>>>>=20 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>=20 >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>> --=20 >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Francis Pouatcha >>>>> Co-Founder and Technical Lead >>>>> adorsys GmbH & Co. KG >>>>> https://adorsys-platform.de/solutions/ = >>>>>=20 >>>>> --=20 >>>>> Francis Pouatcha >>>>> Co-Founder and Technical Lead >>>>> adorsys GmbH & Co. KG >>>>> https://adorsys-platform.de/solutions/ = >>>=20 >>=20 >=20 --Apple-Mail=_333F43BE-9AD2-4847-86EE-2E5746700105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Different use cases are pulling for =E2=80=9Csimplicity=E2=80=9D= in different directions, and I think that we can have a core protocol = that supports these without getting overly convoluted. At least, = that=E2=80=99s the goal!

The rationale for having an RS register in this way is for a = scenario where the AS is the trusted component in the ecosystem. I fully = realize that this is very different from your scenario, where the AS is = not trusted directly by the RS in the same way. Here, the RS wants to = provide a specific runtime reference for what a particular client is = trying to do, independent of any static API definitions for = resources/scopes. In this ecosystem, the AS is trusted to manage and = provision access to all of the RS=E2=80=99s, and the RS=E2=80=99s are = known to the AS ahead of time. Yes, it=E2=80=99s acting as a =E2=80=9Cbig = brother=E2=80=9D as you put it, but that=E2=80=99s the intentional = design =E2=80=94 the RS=E2=80=99s have outsourced portions of their = security and trust to the AS. 

The inspiration for this is UMA=E2=80=99s= federated authorization spec, which I also helped develop:

https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federat= ed-authz-2.0.html

This pattern is in use in the wild, but unfortunately = limitations in OAuth 2 make it more separate from the OAuth ecosystem = than it really ought to be. By bringing this idea of the RS and AS = having a more loose runtime association into GNAP, we can solve not only = the =E2=80=9Cstrong AS=E2=80=9D UMA use cases but also the =E2=80=9Cnaive = AS=E2=80=9D use case that you=E2=80=99re bringing.

 =E2=80=94 = Justin

On Aug 13, 2020, at 9:49 AM, Denis <denis.ietf@free.fr> = wrote:

=20
Justin,

=20 Denis,

This isn=E2=80=99t mandated, this is one optional = flow for the cases where the RS :wants: to talk to the AS.

It is good to know. But what will be the = rational(s) for it ? Token introspection ?
If this is the single case, since token transparency is needed for privacy reasons, it is doubtful that it would still be needed.

If flows can be made simpler, let us make them = simpler.

Denis


 =E2=80=94 Justin

On Aug 12, 2020, at 12:02 PM, Denis <denis.ietf@free.fr> wrote:

=20
Justin,

A soon as the RS needs to talk to the GS (step 2a) , it is a "Big Brother by Design" architecture.
Do you want to mandate it ?

Denis

+1 = to this. I think that the core protocol needs to be designed to allow this kind of action, but I also think it is possible that the details of this could end up in an extension to the main document. I=E2=80=99ve put a flag in the ground for this in XYZ = in sections 10.3 and 10.4, which is adapted from UMA2=E2=80= =99s distributed authorization protocol:

https://tools.ietf.org/html/draft-richer-transact= ional-authz-09#section-10.3

The important detail here, in XYZ=E2=80=99= s design, is that the RS has a clear way to communicate to the client what will be needed to fulfill the request, and the client/orchestrator/whatever has a clear way to incorporate that into the main protocol. The details of (2) using the XYZ pattern are:

+-----------+      +--------------+  +----+ =  +----+  +---------------------+
| Requestor |      | Orchestrator = |  |    |  | GS |  | Resource Controller |
|   was     |    =   |     was      |  = | RS |  | or |  |        =  was         |
|  User     |      = |   Client     |  |    |  = | AS |  |    Resource Owner  =  |
+-----------+      = +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest    =  |            |       |            =     |
  |---------------------->|    =         |       |            =     |
  |          =              |(2) ServiceIntent:AuthZChallenge    =  |
  |          =              |----------->|  =      |            =     |
  |                 =       |            |   =     |                |
  |                 =       |            |(2a) = Register resource set
  |            =            |        =     |------>|          =       |
  |            =            |        =     |       |                = |
  |            =            |        =     |(2b) Return resource reference handle
  |            =            |        =     |<------|          =       |
  |            =            |        =     |       |                = |
  |            =            |(2c) Return AS URL and resource reference handle
  |            =            |<-----------|    =    |            =     |
  |            =            |        =     |       |                = |
  |  =                      |(3) = AuthZRequest(AuthZChallenge, include resource handle)
  |          =              |------------------->|    =             |


Note that the client can ALSO request additional resources on top of what the RS returned in (2b), since this is passed simply as one element of the array. 

 =E2=80=94 Justin

On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <fpo@adorsys.de> wrote:

Hello = Dick,

On = Tue, Aug 11, 2020 at 6:22 PM Dick Hardt = <dick.hardt@gmail.com> wrote:
Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role = (was User). So the UML participant refers to the role "Requestor"


I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
If you make it an = extension, you hide. It shall rather be an optional, integral part of the protocol. If the "Orchestrator/Negotiator/Client" can translate the service request into a resource request, then there will be no need to invoke (2).

When we move beyond = identity management, cases become complex and it makes sense to explicitly display this possibility in the protocol flow.

In some open banking designs, 
- the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2).
- the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

/Francis





On= Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSL= C_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+ =  +----+  +----+ =  +---------------------+
| Requestor |    =   | Orchestrator |  |  =   |  | GS |  | Resource Controller = |
|   was     |      = |     was      |  | RS |  = | or |  |         was        =  |
|  User     |      = |   Client     |  |    |  | AS |  = |    Resource Owner   |
+-----------+    =   +--------------+  +----+  +----+ =  +---------------------+
  |(1) = ServiceRequest     |            = |       |            =     |
  = |---------------------->|          =   |       |          =       |
  |      =                  |(2) = ServiceIntent:AuthZChallenge     |
  |      =                 =  |<---------->|       |          =       |
  |      =                  |  =           = |       |            =     |
  |      =                  |(3) = AuthZRequest(AuthZChallenge)     |
  |      =                 =  |------------------->|            =     |
  |      =                  |  =           = |       |(4) ConsentRequest:Grant
  |      =                  |  =           = |      =  |<-------------->|
  |      =                  |(5) GrantAccess(AuthZ)  =              |
  |      =                 =  |<-------------------|            =     |
  |      =                  |  =           = |       |            =     |
  |      =                  |(6) ServiceRequest(AuthZ):ServiceResponse
  |      =                 =  |<---------->|       |          =       |
  |(7) = ServiceResponse    |            = |       |            =     |
  = |<----------------------|          =   |       |          =       |
  +      =                  +  =           = +       +            =     +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It = starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is = missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear = definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I = agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the = past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
3D""=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu> wrote:
I=E2=80=99m = in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really = in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D= and come up with a new, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D = as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D = to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t = use the term =E2=80=9Cconsumer=E2= =80=9D at all, nor does it use =E2=80=9Cserver=E2=80=9D = on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D.

GNAP can = do something similar, in my opinion. But what we can=E2=80=99t do is = ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth = 2 and its terminology. We don=E2=80=99t have a = blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be = a delicate balance!

 =E2=80= =94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:

I think that is fundamentally part of the = question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
= confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word = continues.

Food for = thought.
- Warren

=
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture. = Implement Authress.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk = <kaduk@mit.edu> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think = there=E2=80=99s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a =
> > =E2=80=9CClient=E2= =80=9D in OAuth parlance because it is /a client of RS1/. What you
> > call = a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t = using the same terms.
> >
> > The good news is that this isn=E2=80=99t = OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99= t just re-use existing terms with new definitions, =
> > but we=E2=80=99ve = got a chance to be more precise with how we define = things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  = We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
= confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
--
= Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">

--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">
--
TXAuth mailing list
= TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br class=3D"">


--
=
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/





= --Apple-Mail=_333F43BE-9AD2-4847-86EE-2E5746700105-- From nobody Thu Aug 13 07:59:58 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 7DE943A0CF1 for ; Thu, 13 Aug 2020 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 s23x7tRs6beH for ; Thu, 13 Aug 2020 07:59:49 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 9FDBF3A0CEE for ; Thu, 13 Aug 2020 07:59:49 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id r13so1361337iln.0 for ; Thu, 13 Aug 2020 07:59:49 -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=cL8eH8m3CBf1CjqzGsH72+Pon+2iyJVPxsHdMPjFMaY=; b=O/2Vd+wFsLT2DQWol4c1RooPtLI1lGS7VJZ+niGuv6f2g48e/YgeAzeivDsNdHrIP7 OE9bGspbH5UwnZXZFVVLVPzsFZ5uHcne1Gph4S4YAbXCf2nJ9OeelLPH5s/7Dv6cRieC 3Zfkx4oqv6H7/KNe8ubDzw3dtBb5NwcaLhs5Pn7A3OoJBtQxGzSoez2wPWiZJCtbv0GO yT0HyjhFfuODTZa0HpA/cDfnTpHtmPFXVJ0QMEi+JC8WcWOnf5dbL3pp22vwKfYXrlCZ Fk4boT3Com2bfsERtzOmNczgluUmNwOwCJfdR7OcNPa4BXurxtJ6kviwP9bSd16oWhke 1nYA== 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=cL8eH8m3CBf1CjqzGsH72+Pon+2iyJVPxsHdMPjFMaY=; b=fXEwdM11c5JMroEM/vz+kcsAiT52XD4ylou1ipr4qGPEo0pWa4U71XGGVGizFMl+Wu UCcTGPuLKOkXt1SpWTnT2Jflr5rIwfornCVSO+8fImGq/UcKmvolCoFSDuaYGWt1Cy1b 7A3Zte5Yo99TeMIJ+gFR36XoEDJV+jROMFOT/GSynhyOSNTR8ROWWCTFJzPZ6P9NxAlG vThNCODXz7wGdAAJe19zjpYsCTo17KNHaa0MDWc2CsY/IAGDd1zyGk1f+QwZ5PB8yJlF BOhnWbfwQ2D6KFtUfGITEr59mrRqJv+KRKZSn/fzLiDvKgS2XiLb9ctBy6kgUf77TvAG zmyw== X-Gm-Message-State: AOAM530eT33HZ1OJ/thRv5JHq1NrtpLnhNHx3QtBpIhqEECVZZaZssyy QgR0JIBkHncc4WRfrgESc/Due356qStwOVxTNuc= X-Google-Smtp-Source: ABdhPJyysw6JDnFLr+ccXLSGUisZArq7CGeMZgsXRAyO5k+tv9Z9NFw8i1XNvGpwTA29Cl0HueXYpMECdOzjQbVG/xs= X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr4694503ils.188.1597330788803; Thu, 13 Aug 2020 07:59:48 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> In-Reply-To: <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> From: Fabien Imbault Date: Thu, 13 Aug 2020 16:59:36 +0200 Message-ID: To: Denis Cc: Dave Tonge , Justin Richer , Dick Hardt , Mike Jones , Tom Jones , Francis Pouatcha , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000416a8505acc38ee2" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 13 Aug 2020 14:59:57 -0000 --000000000000416a8505acc38ee2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable An attempt. * =3D application that requests access to Resource Servers (RS) through a Grant Server (GS). * Examples: a web server, a browser-based app, a mobile app, an IoT device. *GS =3D computing service that manages the grant lifecycle to a on behalf of a Resource Controler (RC).* Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested. *RS =3D computing service that grants access only if its Resource Controler (RC) consents.* Note : the consent may involve a human interaction or may be automated based on access control policies. *RC =3D entity which is controlling the access to a protected resource. * Note : a RC may be manually operated by a human or delegated to a machine, partially or completely. *Consent =3D the process of asking a RC to accept or decline based on a gra= nt request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D or =E2=80= =9Cno=E2=80=9D consent decision.* Fabien On Thu, Aug 13, 2020 at 3:55 PM Denis wrote: > Fabien, > > IMHO, nothing is wrong with keeping "Client" since it has a wide spread > usage > ... but only as long as we can agree on a short and a clear definition fo= r > it. > > I can provide the beginning of such a definition: " application ..." > > If someone could go a little bit further, this would help. :-) > > A similar argumentation for GS. It could be used but only as long as we > can agree on a short and a clear definition for it. > Any proposal ? > > Denis > > Hi, > > Nothing inherently wrong with Client/AS, which has worked for years in th= e > context of OAuth2. The question is to know whether we can build the new > protocol with the same concepts and deal with their known limitations, or > if we're better off with more adapted concepts less prone to > misunderstandings. > > Verb vs Noun: > Problem is that the grant (noun) can only be understood if there is a > grant(verb), i.e. some action that grants something. > The grant (noun) definition directly derives from the verb : "something > granted ..." > > I personally have no issue even with the fairly convoluted "The Grant > Server issues a grant to the Grant Client representing access that has be= en > granted" (except perhaps from the word Client, but that's a different > issue). > By the way, grant is nothing new, it's used extensively in OAuth2 as > "grant types" (whatever that means). > > Dick summarized well the reasons why he uses GS instead of AS : > 1) "grant" is in the working group name (a weaker reason, but still has > been approved). Question: would our reasoning if the protocol ended up > being called OAuth3? > 2) grant =3D larger in scope than AS (not only authorization), as it at > least includes idclaims + other use cases like payment (?) - no consensus= , > see difference in appreciation between Justin and Dick > > As for "Client", if most people think it is problematic, it seems a good > reason to change if we find a better alternative. > Quoting Dick again: "The confusion in my experience usually stems from > people working with software that is acting in multiple roles. IE, the > software that is acting as a client in once context, is also acting as an > RS in other contexts, or even acting as an AS. The other confusion is tha= t > people view clients as being the software the user is using -- although > it may not be acting as a client in the oauth context." and later "I do > agree that it is not the best term in GNAP. Primarily because GNAP is a > combination of the client from OAuth 2, and the relying party from OIDC." > > So far there's no consensus however, recent tries: Initiating Application > (Denis), Orchestrator (Francis). > > Cheers > Fabien > > > > > On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge > wrote: > >> I would be against using "grant" as both a verb and a noun and stick >> purely with one or the other. (In the charter the only use of "grant" is= in >> the verb: "granted"). >> >> Using it as both a verb and a noun will be confusing and less accessible= . >> >> I think it will be confusing to say "The Grant Server issues a grant to >> the Grant Client representing access that has been granted" >> >> Whether the access takes place via a token being returned and used at a >> resource server, or "claims" that are directly returned from the "Grant >> Server" I think should be largely irrelevant when it comes to the naming= of >> the roles. >> >> In almost all use cases that I have seen the "Grant Server" is making a >> policy based decision "to grant" access to requested resource(s). To me, >> that is the fundamental operation happening. I think nearly all use case= s >> can be applied to that, e.g. the GS grants access to >> - identity attributes for the end user >> - verify an identity attribute (e.g. that user is over 18) >> - all users photos at resource server X >> - a single photo with id 12345 at resource server Y >> - resource of type X at any resource server that trusts the Grant Serve= r >> - call a payment API with specific properties (e.g. amount < 5) >> - call a file storage API >> - call a "contract signing" API with specific properties (e.g. contract >> hash of xxx,) >> >> While "client" is problematic, it does now have wide spread usage, so >> perhaps we are stuck with it. >> However I agree with Justin and think "Grant Client" makes things more >> confusing. >> >> What is wrong with keeping "Client" and "Authorization Server"? >> >> Dave >> >> >> >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> > --000000000000416a8505acc38ee2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An attempt.

<Clie= nt> =3D application that requests access to Resource Servers (RS) throug= h a Grant Server (GS).=C2=A0=C2=A0
Examples: a=C2=A0web serve= r, a browser-based app, a mobile app, an IoT device.

<= /div>
GS =3D computing service that manages the grant lifecycle=C2= =A0to a <Client> on behalf of a Resource Controler (RC).
Note : for privacy reasons, the GS may be issuing grants without knowledg= e of which resources are requested.

RS = =3D computing service that grants access only if its Resource Controler (RC= ) consents.
Note : the consent may involve a human interactio= n or may be automated based on access control policies.

RC =3D entity which is controlling the access to a protected resou= rce.=C2=A0
Note : a RC may be manually operated by a human or= delegated to a machine, partially or completely.

= Consent =3D the process of asking a RC to accept or decline based on a g= rant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D or = =E2=80=9Cno=E2=80=9D consent decision.

F= abien

On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Fabien,

IMHO, nothing is wrong with keeping "Client" since it has a wide spread = usage
... but only as long as we can agree on a short and a clear definition for it.
I can provide the beginning of such a definition: " application ..."

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.=C2=A0 It could be used but only as long as we can agree on a short and a clear definition for it.
Any proposal ?

Denis

=20
Hi,

Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings.=

Verb vs Noun:
Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something.=C2=A0
The grant (noun) definition directly derives from the verb : "something granted ..."

I personally=C2=A0have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perhaps from the word Client, but that&= #39;s a different issue).
By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types"= ; (whatever that means).=C2=A0

Dick summarized well the reasons why he uses GS instead of AS :=C2=A0<= /div>
1) "grant"= is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
2) grant =3D larger in scope than AS (not only authorization), as it at least includes idclaims=C2=A0+ other use cases like payment (?) - n= o consensus, see difference in appreciation between Justin and Dick

As for "Client&= quot;, if most people think it is problematic, it seems a good reason to change if we find a better alternative.=C2=A0
Quoting Dick again: "The confusion in my experience usually stems fro= m people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0roles. IE, the software=C2=A0that is acting as a= =C2=A0client=C2=A0in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view=C2=A0clients=C2=A0as being the software the user is using -- although it may not be acting as a=C2=A0= client=C2=A0in the oauth context." and later "I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the=C2=A0clien= t=C2=A0from OAuth 2, and the relying party from OIDC."

So far there's n= o consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis).=C2=A0

Cheers
Fabien




On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I would be against using "grant" as both a verb and a noun and stick p= urely with one or the other. (In the charter the only use of "grant" is in the verb: "granted"= ;).

Using it as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted"

Whether the access takes place via a token being returned and used at a resource server, or "claims" that are d= irectly returned from the "Grant Server" I think should b= e largely irrelevant when it comes to the naming of the roles.

In almost all use cases that I have seen the "Grant Serve= r" is making a policy based decision "to grant" acce= ss to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
=C2=A0- identity=C2=A0attributes for the end user
=C2=A0- verify=C2=A0an identity attribute (e.g. that user is over 1= 8)
=C2=A0- all users photos at resource server X
=C2=A0- a single photo with id 12345 at resource server Y
=C2=A0- resource of type X at any resource server that trusts the Grant Server
=C2=A0- call a payment API with specific properties (e.g. amount < 5)
=C2=A0- call a file storage API
=C2=A0- call a "contract signing" API with specific prope= rties (e.g. contract hash of xxx,)
=C2=A0
While "client" is problematic, it does now have wide sp= read usage, so perhaps we are stuck with it.=C2=A0
However I agree with Justin and think "Grant Client" make= s things more confusing.

What is wrong with keeping "Client" and "Authoriz= ation Server"?=C2=A0

Dave




Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIM= ER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business= . Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.



--000000000000416a8505acc38ee2-- From nobody Thu Aug 13 08:00:08 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 80EE43A0D05 for ; Thu, 13 Aug 2020 07:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 6GMljjXewv_U for ; Thu, 13 Aug 2020 07:59:57 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 5DA2D3A0CFA for ; Thu, 13 Aug 2020 07:59:56 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id n128so1450265oif.0 for ; Thu, 13 Aug 2020 07:59:56 -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=GTKrLehP7L2nBykdm5El+3R+SOQdQfvwi/MXjF6PzpY=; b=evmGH5QH/8XWv+S2GnAiLcQ3NYSHgJyhuCwpgwTOnj4jVPoOwdonTVUiUnHYnqUFtZ do4kM6AeZxG8g0L90bunRB8bt7RhqWcF7wRH8ViVw73BPfDQjGku5pVi4mxf7EiK7vM8 grHnzAgbmln86MpGOD3QVuRLpdAEWpCQZcifUUPDUuc6V7gQk0+qk0uRvWGMfpSunUs1 W7oMev7V1AuyRW8Edhh5xZjuVzjx6FdvZHUh9VTpCqsKZZ6fNeWtkCCJKRoNuMsoKPLN JchKaoieTncP/w42C9YssfdO420nb/ef+UkwejERJa+M8FvuIr3aThzeNXgMYtzsgEZT fNDA== 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=GTKrLehP7L2nBykdm5El+3R+SOQdQfvwi/MXjF6PzpY=; b=GI7Nd1dgyVQP62XuIVxgVbPPbWJdvkedx8tw6RH9TPM7ZGiXgyYJmTvprxyq9brEcq WZRCIsYd6BTLnlqkm/HyfrFkO7ThjQWpkN6U68T1aN8eoUmxbaqdQQ5Jo6O8Xzxm9t2Z qBrRKN8dTXUQa1rHBx46xRUvPj5jWNNSRyi/kW2xS/WHUPFsB9+Xg2+Zeh6L4H2P8/Mj 8kOBVpy/awepxPJAa12GdwSVYWYcaszMEA3g1R/w2SNWFsU3wvY4aLP7IaF2tEruv2IS H/PSM9A2T/5+TIMBvSoNjKLB7PhTjeRitCb5gIJVlvw5AR6dEvEeyzIHS41RhUOqTrhv kv/w== X-Gm-Message-State: AOAM5308egQ3wRi+MUXnHteX2WMymG125sUE0NGgx7gDUqph0TkAvaGU 0J/Qejd9fs6GTvXc1lJ3D3KQcuOHQ1obko2Pef0= X-Google-Smtp-Source: ABdhPJyYA3NhJ4laPiNdGiPp3WxQg2F6tVB2waCEBut0TwLia3SwZltZEx+UnRhrQUTav1YgByC+EU5WhsfVOF5DA4M= X-Received: by 2002:a54:448f:: with SMTP id v15mr3772374oiv.172.1597330795500; Thu, 13 Aug 2020 07:59:55 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> In-Reply-To: <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> From: Tom Jones Date: Thu, 13 Aug 2020 07:59:43 -0700 Message-ID: To: Justin Richer Cc: Dick Hardt , Francis Pouatcha , Denis , Benjamin James Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a79ad605acc38ec9" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:00:01 -0000 --000000000000a79ad605acc38ec9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented. users are human in my language. Peace ..tom On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: > If defined as the party operating the client software, then the user is a > role. I believe this is more accurate and inclusive than the definition y= ou > have proposed with the user as an entity. > > - Justin > ________________________________________ > From: Dick Hardt [dick.hardt@gmail.com] > Sent: Tuesday, August 11, 2020 6:21 PM > To: Francis Pouatcha > Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org > Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a > driving use case for the creation of OAuth) > > Hi Francis > > The user is an entity, not a role in the protocol in how I am defining > roles, so steps (1) and (7) are confusing to me on what is happening. > > I also think that (2) could be an extension to GNAP, rather than part of > the core protocol. > > > > > > On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha fpo@adorsys.de>> wrote: > In this context, I suggest we pick some words to work with, and sharpen > them as we move on, discover and map new use cases to the protocol. > > In this diagram from the original thread ( > https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= ), > I replaced the words: > > +-----------+ +--------------+ +----+ +----+ > +---------------------+ > | Requestor | | Orchestrator | | | | GS | | Resource Controlle= r > | > | was | | was | | RS | | or | | was > | > | User | | Client | | | | AS | | Resource Owner > | > +-----------+ +--------------+ +----+ +----+ > +---------------------+ > |(1) ServiceRequest | | | | > |---------------------->| | | | > | |(2) ServiceIntent:AuthZChallenge | > | |<---------->| | | > | | | | | > | |(3) AuthZRequest(AuthZChallenge) | > | |------------------->| | > | | | |(4) ConsentRequest:Grant > | | | |<-------------->| > | |(5) GrantAccess(AuthZ) | > | |<-------------------| | > | | | | | > | |(6) ServiceRequest(AuthZ):ServiceResponse > | |<---------->| | | > |(7) ServiceResponse | | | | > |<----------------------| | | | > + + + + + > > The purpose of the GNAP protocol is to help negotiate access to a > protected resource. It starts with a requestor delegating activity to an > orchestrator. These are all roles, no entities. Let focus on mapping the > use cases to the protocol roles and interactions so wwe can discover what > is missing. > > It seems cumbersome to use it in discussions as it is impossible to give > the word "Client" a clear definition. > > We can mention in the final document, that the "Orchestrator" (or whateve= r > word we finally use) plays the same role as the "Client" in oAuth2. > > Best regards. > /Francis > > > > > > On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt dick.hardt@gmail.com>> wrote: > I agree with Justin. Redefining well used terms will lead to significant > confusion. If we have a different role than what we have had in the past, > then that role should have a name not being used already in OAuth or OIDC= . > > Given what we have learned, and my own experience explaining what a Clien= t > is, and is not, improving the definition for Client could prove useful. I > am not suggesting the term be redefined, but clarified. > > For example, clarifying that a Client is a role an entity plays in the > protocol, and that the same entity may play other roles at other times, o= r > some other language to help differentiate between "role" and "entity". > > /Dick > [ > https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D= &type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7 > > > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer jricher@mit.edu>> wrote: > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better= fit, but I=E2=80=99m not > really in favor of taking an existing term and applying a completely new > definition to it. In other words, I would sooner stop using =E2=80=9Cclie= nt=E2=80=9D and > come up with a new, more specific and accurate term for the role than to > define =E2=80=9Cclient=E2=80=9D as meaning something completely different= . We did this in > going from OAuth 1 to OAuth 2 already, moving from the even-more-confusin= g > =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, > nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead always qu= alifies it with > =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CResource Server=E2=80= =9D. > > GNAP can do something similar, in my opinion. But what we can=E2=80=99t d= o is > ignore the fact that GNAP is going to be coming up in a world that is > already permeated by OAuth 2 and its terminology. We don=E2=80=99t have = a blank > slate to work with, but neither are we bound to use the same terms and > constructs as before. It=E2=80=99s going to be a delicate balance! > > =E2=80=94 Justin > > On Aug 4, 2020, at 3:32 PM, Warren Parad wparad@rhosys.ch>> wrote: > > I think that is fundamentally part of the question: > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion > > If we say that this document assumes OAuth2.0 terminology, then we should > not change the meanings of any definition. If we are saying this supersed= es > or replaces what OAuth 2.0 creates, then we should pick the best word for > the job and ignore conflicting meanings from OAuth 2.0. I have a lot of > first hand experience of industries "ruining words", and attempting to > side-step the problem rather than redefining the word just confuses > everyone as everyone forgets the original meaning as new documents come > out, but the confusion with the use of a non-obvious word continues. > > Food for thought. > - Warren > > [ > https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW= 56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm= 9GCeBRRzrSc8kWcUSNtuA > ] > > Warren Parad > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress. > > > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk kaduk@mit.edu>> wrote: > Hi Denis, > > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > > > > Since you replied in parallel, I will make a response similar to the on= e > > I sent to Dick. > > > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in use h= ere. What > > > you describe as RS2, which might in fact be an RS unto itself, is a > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client of= RS1/. What you > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, b= ut it is not at > > > all the same as an OAuth client. I appreciate your mapping of the > > > entities below, but it makes it difficult to hold a discussion if we > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we ca= n define > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new def= initions, > > > but we=E2=80=99ve got a chance to be more precise with how we define = things. > > > > In the ISO context, each document must define its own terminology. The > > boiler plate for RFCs does not mandate a terminology or definitions > section > > but does not prevent it either. The vocabulary is limited and as long a= s > > we clearly define what our terms are meaning, we can re-use a term > already > > used in another RFC. This is also the ISO approach. > > Just because we can do something does not necessarily mean that it is a > good idea to do so. We are clear that we are producing a protocol that i= s > conceptually (if not more strongly) related to OAuth 2.0, and reusing ter= ms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted Dick = to > use the term "GS" in XAuth, picking a name that was not already used in > OAuth 2.0. > > -Ben > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- > 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a79ad605acc38ec9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I strong object to the objectification of human users. It = is way past time that the IETF becaume user oriented instead of web service= oriented.
users are human in my language.
Peace ..tom


<= div class=3D"gmail_quote">
On Tue, Aug= 11, 2020 at 4:38 PM Justin Richer <j= richer@mit.edu> wrote:
If defined as the party operating the client software, then t= he user is a role. I believe this is more accurate and inclusive than the d= efinition you have proposed with the user as an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a drivin= g use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining role= s, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of th= e core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen the= m as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOB= JqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+=C2=A0 +----+=C2=A0 +----= +=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator |=C2=A0 |=C2=A0 =C2=A0 |= =C2=A0 | GS |=C2=A0 | Resource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client= =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |=C2=A0 =C2= =A0 Resource Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+=C2=A0 +----+=C2=A0 +----= +=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =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) ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected= resource. It starts with a requestor delegating activity to an orchestrato= r. These are all roles, no entities. Let focus on mapping the use cases to = the protocol roles and interactions so wwe can discover what is missing.
It seems cumbersome to use it in discussions as it is impossible to give th= e word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or= whatever word we finally use) plays the same role as the "Client"= ; in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
I agree with Justin. Redefining well used terms will lead to significant co= nfusion. If we have a different role than what we have had in the past, the= n that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client = is, and is not, improving the definition for Client could prove useful. I a= m not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the prot= ocol, and that the same entity may play other roles at other times, or some= other language to help differentiate between "role" and "en= tity".

/Dick
[https://mailfoogae.a= ppspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=3Dzeroconten= t&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto= :jricher@mit.edu&g= t;> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better f= it, but I=E2=80=99m not really in favor of taking an existing term and appl= ying a completely new definition to it. In other words, I would sooner stop= using =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and a= ccurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meanin= g something completely different. We did this in going from OAuth 1 to OAut= h 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D= to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2= =80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2=80=9D on= its own but instead always qualifies it with =E2=80=9CAuthorization Server= =E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do = is ignore the fact that GNAP is going to be coming up in a world that is al= ready permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have= a blank slate to work with, but neither are we bound to use the same terms= and constructs as before. It=E2=80=99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should n= ot change the meanings of any definition. If we are saying this supersedes = or replaces what OAuth 2.0 creates, then we should pick the best word for t= he job and ignore conflicting meanings from OAuth 2.0. I have a lot of firs= t hand experience of industries "ruining words", and attempting t= o side-step the problem rather than redefining the word just confuses every= one as everyone forgets the original meaning as new documents come out, but= the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https= ://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A7= 4mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRR= zrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Impleme= nt Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<= ;mailto:Txauth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<= ;mailto:Txauth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<= ;mailto:TXAuth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<= ;mailto:TXAuth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth


--
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
--000000000000a79ad605acc38ec9-- From nobody Thu Aug 13 08:11:13 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 3AD453A0CCE for ; Thu, 13 Aug 2020 08:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yxllZLQInL_X for ; Thu, 13 Aug 2020 08:11:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AD73A0CCA for ; Thu, 13 Aug 2020 08:11:06 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DFAxSC024028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 11:11:00 -0400 From: Justin Richer Message-Id: <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_3DF32CC6-88E0-4CB7-B7EE-2490A4967EBD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 11:10:58 -0400 In-Reply-To: Cc: Dick Hardt , Francis Pouatcha , Denis , Benjamin James Kaduk , "txauth@ietf.org" To: Tom Jones References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:11:11 -0000 --Apple-Mail=_3DF32CC6-88E0-4CB7-B7EE-2490A4967EBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure where = the objection you=E2=80=99re raising comes from. Also, whatever roles we define here, whether software or human-ware, = they need to be related to the protocol. =E2=80=94 Justin > On Aug 13, 2020, at 10:59 AM, Tom Jones = wrote: >=20 > I strong object to the objectification of human users. It is way past = time that the IETF becaume user oriented instead of web service = oriented. > users are human in my language. > Peace ..tom >=20 >=20 > On Tue, Aug 11, 2020 at 4:38 PM Justin Richer > wrote: > If defined as the party operating the client software, then the user = is a role. I believe this is more accurate and inclusive than the = definition you have proposed with the user as an entity.=20 >=20 > - Justin > ________________________________________ > From: Dick Hardt [dick.hardt@gmail.com ] > Sent: Tuesday, August 11, 2020 6:21 PM > To: Francis Pouatcha > Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org = > Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a = driving use case for the creation of OAuth) >=20 > Hi Francis >=20 > The user is an entity, not a role in the protocol in how I am defining = roles, so steps (1) and (7) are confusing to me on what is happening. >=20 > I also think that (2) could be an extension to GNAP, rather than part = of the core protocol. >=20 >=20 >=20 >=20 >=20 > On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >> = wrote: > In this context, I suggest we pick some words to work with, and = sharpen them as we move on, discover and map new use cases to the = protocol. >=20 > In this diagram from the original thread = (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/= = ), I replaced the words: >=20 > +-----------+ +--------------+ +----+ +----+ = +---------------------+ > | Requestor | | Orchestrator | | | | GS | | Resource = Controller | > | was | | was | | RS | | or | | was = | > | User | | Client | | | | AS | | Resource = Owner | > +-----------+ +--------------+ +----+ +----+ = +---------------------+ > |(1) ServiceRequest | | | | > |---------------------->| | | | > | |(2) ServiceIntent:AuthZChallenge | > | |<---------->| | | > | | | | | > | |(3) AuthZRequest(AuthZChallenge) | > | |------------------->| | > | | | |(4) = ConsentRequest:Grant > | | | |<-------------->| > | |(5) GrantAccess(AuthZ) | > | |<-------------------| | > | | | | | > | |(6) ServiceRequest(AuthZ):ServiceResponse > | |<---------->| | | > |(7) ServiceResponse | | | | > |<----------------------| | | | > + + + + + >=20 > The purpose of the GNAP protocol is to help negotiate access to a = protected resource. It starts with a requestor delegating activity to an = orchestrator. These are all roles, no entities. Let focus on mapping the = use cases to the protocol roles and interactions so wwe can discover = what is missing. >=20 > It seems cumbersome to use it in discussions as it is impossible to = give the word "Client" a clear definition. >=20 > We can mention in the final document, that the "Orchestrator" (or = whatever word we finally use) plays the same role as the "Client" in = oAuth2. >=20 > Best regards. > /Francis >=20 >=20 >=20 >=20 >=20 > On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >> wrote: > I agree with Justin. Redefining well used terms will lead to = significant confusion. If we have a different role than what we have had = in the past, then that role should have a name not being used already in = OAuth or OIDC. >=20 > Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified. >=20 > For example, clarifying that a Client is a role an entity plays in the = protocol, and that the same entity may play other roles at other times, = or some other language to help differentiate between "role" and = "entity". >=20 > /Dick > = [https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D= &type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7 = = >=20 > On Wed, Aug 5, 2020 at 8:20 AM Justin Richer = >> = wrote: > I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >=20 > GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is ignore the fact that GNAP is going to be coming up in a world that = is already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance! >=20 > =E2=80=94 Justin >=20 > On Aug 4, 2020, at 3:32 PM, Warren Parad >> wrote: >=20 > I think that is fundamentally part of the question: > We are clear that we are producing a protocol that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion >=20 > If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues. >=20 > Food for thought. > - Warren >=20 > = [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW= 56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuI= m9GCeBRRzrSc8kWcUSNtuA = ] >=20 > Warren Parad > Founder, CTO >=20 > Secure your user data and complete your authorization architecture. = Implement Authress.ly/37SSO1p>. >=20 >=20 > On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >> = wrote: > Hi Denis, >=20 > On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: > > Hi Justin, > > > > Since you replied in parallel, I will make a response similar to the = one > > I sent to Dick. > > > > > Hi Denis, > > > > > > I think there=E2=80=99s still a problem with the terminology in = use here. What > > > you describe as RS2, which might in fact be an RS unto itself, is = a > > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you > > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at > > > all the same as an OAuth client. I appreciate your mapping of the > > > entities below, but it makes it difficult to hold a discussion if = we > > > aren=E2=80=99t using the same terms. > > > > > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can define > > > our own terms. The bad news is that this is really hard to do. > > > > > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new = definitions, > > > but we=E2=80=99ve got a chance to be more precise with how we = define things. > > > > In the ISO context, each document must define its own terminology. = The > > boiler plate for RFCs does not mandate a terminology or definitions = section > > but does not prevent it either. The vocabulary is limited and as = long as > > we clearly define what our terms are meaning, we can re-use a term = already > > used in another RFC. This is also the ISO approach. >=20 > Just because we can do something does not necessarily mean that it is = a > good idea to do so. We are clear that we are producing a protocol = that is > conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms > from OAuth 2.0 but with different definitions may lead to unnecessary > confusion. If I understand correctly, a similar reasoning prompted = Dick to > use the term "GS" in XAuth, picking a name that was not already used = in > OAuth 2.0. >=20 > -Ben >=20 > -- > Txauth mailing list > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = > -- > Txauth mailing list > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 > -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = > -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_3DF32CC6-88E0-4CB7-B7EE-2490A4967EBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not = sure where the objection you=E2=80=99re raising comes from.

Also, whatever roles we = define here, whether software or human-ware, they need to be related to = the protocol.

 =E2=80=94 Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the = objectification of human users. It is way past time that the IETF = becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin = Richer <jricher@mit.edu> wrote:
If defined as the party = operating the client software, then the user is a role. I believe this = is more accurate and inclusive than the definition you have proposed = with the user as an entity.

 - Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a = driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining = roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of = the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen = them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqd= mQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  = +----+  +---------------------+
| Requestor |      | Orchestrator |  |    = |  | GS |  | Resource Controller |
|   was     |      |  =    was      |  | RS |  | or |  = |         was        =  |
|  User     |      |  =  Client     |  |    |  | AS = |  |    Resource Owner   |
+-----------+      +--------------+  +----+  = +----+  +---------------------+
  |(1) ServiceRequest     |      =       |       |      =           |
  |---------------------->|          =   |       |          =       |
  |                  =      |(2) ServiceIntent:AuthZChallenge    =  |
  |                  =      |<---------->|      =  |                |
  |                  =      |            |  =      |              =   |
  |                  =      |(3) AuthZRequest(AuthZChallenge)    =  |
  |                  =      |------------------->|        =         |
  |                  =      |            |  =      |(4) ConsentRequest:Grant
  |                  =      |            |  =      |<-------------->|
  |                  =      |(5) GrantAccess(AuthZ)        =        |
  |                  =      |<-------------------|        =         |
  |                  =      |            |  =      |              =   |
  |                  =      |(6) ServiceRequest(AuthZ):ServiceResponse
  |                  =      |<---------->|      =  |                |
  |(7) ServiceResponse    |        =     |       |        =         |
  |<----------------------|          =   |       |          =       |
  +                  =      +            +  =      +              =   +

The purpose of the GNAP protocol is to help negotiate access to a = protected resource. It starts with a requestor delegating activity to an = orchestrator. These are all roles, no entities. Let focus on mapping the = use cases to the protocol roles and interactions so wwe can discover = what is missing.

It seems cumbersome to use it in discussions as it is impossible to give = the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or = whatever word we finally use) plays the same role as the "Client" in = oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant = confusion. If we have a different role than what we have had in the = past, then that role should have a name not being used already in OAuth = or OIDC.

Given what we have learned, and my own experience explaining what a = Client is, and is not, improving the definition for Client could prove = useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the = protocol, and that the same entity may play other roles at other times, = or some other language to help differentiate between "role" and = "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFp= bC5jb20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e0= 0dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer = <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but I=E2=80=99m not really in favor of taking an existing = term and applying a completely new definition to it. In other words, I = would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new, = more specific and accurate term for the role than to define =E2=80=9Cclien= t=E2=80=9D as meaning something completely different. We did this in = going from OAuth 1 to OAuth 2 already, moving from the = even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D= , but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at = all, nor does it use =E2=80=9Cserver=E2=80=9D on its own but instead = always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is ignore the fact that GNAP is going to be coming up in a world that = is already permeated  by OAuth 2 and its terminology. We don=E2=80=99= t have a blank slate to work with, but neither are we bound to use the = same terms and constructs as before. It=E2=80=99s going to be a delicate = balance!

 =E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we = should not change the meanings of any definition. If we are saying this = supersedes or replaces what OAuth 2.0 creates, then we should pick the = best word for the job and ignore conflicting meanings from OAuth 2.0. I = have a lot of first hand experience of industries "ruining words", and = attempting to side-step the problem rather than redefining the word just = confuses everyone as everyone forgets the original meaning as new = documents come out, but the confusion with the use of a non-obvious word = continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRX= sqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHo= gY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. = Implement Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to = the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology = in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, = is a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a = client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth = world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of = the
> > entities below, but it makes it difficult to hold a discussion = if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new = WG we can define
> > our own terms. The bad news is that this is really hard to = do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with = new definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we = define things.
>
> In the ISO context, each document must define its own terminology. = The
> boiler plate for RFCs does not mandate a terminology or definitions = section
> but does not prevent it either. The vocabulary is limited and as = long as
> we clearly define what our terms are meaning, we can re-use a term = already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is = a
good idea to do so.  We are clear that we are producing a protocol = that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing = terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted = Dick to
use the term "GS" in XAuth, picking a name that was not already used = in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
= --
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
= --
TXAuth mailing list
TXAuth@ietf.org<mailto: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/ --
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_3DF32CC6-88E0-4CB7-B7EE-2490A4967EBD-- From nobody Thu Aug 13 08:15:36 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 7E9013A0D0D for ; Thu, 13 Aug 2020 08:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mbHZvV3TNwzF for ; Thu, 13 Aug 2020 08:15:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979633A0D08 for ; Thu, 13 Aug 2020 08:15:32 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DFFRjP025945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 11:15:28 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E0FECA11-710B-4D60-BCA3-EF56BFFC26BF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 11:15:27 -0400 In-Reply-To: <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> Cc: Dick Hardt , Francis Pouatcha , Benjamin Kaduk , "txauth@ietf.org" To: Denis References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:15:34 -0000 --Apple-Mail=_E0FECA11-710B-4D60-BCA3-EF56BFFC26BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis, I want to focus on one point here: > In OAuth 2.0, the user consent is performed by the AS using an = authorize endpoint where the user consent is solicited and captured. >=20 > Since a user, with no prior experience, shall first connect to a RS to = perform an operation, the user consent shall be performed by the RS,=20 > instead of the AS. This means that we should define a "consent" = endpoint at the RS. One of my goals with XYZ=E2=80=99s design was to be able to separate the = interaction with the user from the web-based flows for the delegation = protocol, and that aspect is enshrined in the GNAP charter as well. It points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner.=20 We already saw bits of this in OAuth 2: the AS is defined by the pair of = the token endpoint and authorization endpoint, each filling the = respective roles above. What if we formally separate these? Strawman = names: Delegation Server (DS) - handles the back-channel stuff Interaction Server (IS) - handles the front-channel stuff =E2=80=94 Justin --Apple-Mail=_E0FECA11-710B-4D60-BCA3-EF56BFFC26BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis, I want to focus on one point here:

In OAuth 2.0, the = user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with = no prior experience, shall first connect to a RS to perform an operation, the= user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the = RS.

One of my goals = with XYZ=E2=80=99s design was to be able to separate the interaction = with the user from the web-based flows for the delegation protocol, and = that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two = different aspects of the traditional AS that we might need to talk about = separately now. One deals with delegation, issuing tokens, returning = data directly to the client (not through a separate API, since that=E2=80=99= s the RS), and other back-channel stuff. The other aspect deals with = interacting with the user and/or resource owner. 

We already saw bits of this in OAuth 2: the AS is = defined by the pair of the token endpoint and authorization endpoint, = each filling the respective roles above. What if we formally separate = these? Strawman names:


Delegation Server (DS) - handles the back-channel = stuff

Interaction Server (IS) - = handles the front-channel stuff


 =E2=80=94 Justin

= --Apple-Mail=_E0FECA11-710B-4D60-BCA3-EF56BFFC26BF-- From nobody Thu Aug 13 08:18:06 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 152E43A0D47 for ; Thu, 13 Aug 2020 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 PaOJd7XW0ZuW for ; Thu, 13 Aug 2020 08:18:02 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 885F73A0D4A for ; Thu, 13 Aug 2020 08:18:02 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id u126so7577863iod.12 for ; Thu, 13 Aug 2020 08:18:02 -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=2m45iFZWfBBb60NUHuTSes9bEOG6qD90s/gv4JpU4dA=; b=b08Uc89Zvw+BrLT8L4Z1uNvyvJY9jXBdGUepS9q5alQujRoYkjzYhUBQl9AeROwFrW vqjMe2MOMiZXiKKDYWifZ7SBAX4FZQmKX9r8MhS5ZJ5lQ8rfIhtKgenx8fKdgoLJDbq+ Bvx34nr1NFxY3jvNjgc91EWY53T3ErRTK63y1HWa88DMXbe91ATvMBw8zOmtP0ZGW2fF 86MojDMLLuCXcDtuPpFxZX7OniwEYo32sYTFbUlGQ55+ZarAr+epbTZeympft9dRxojg ckfZGcuJX0knP5WNk05T3UmDUvJgj2sZkuOMlVprAYIYK57J6bPe9klIfxnjuaQC96+w NQKA== 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=2m45iFZWfBBb60NUHuTSes9bEOG6qD90s/gv4JpU4dA=; b=errFjRbtggleZs6F/woBQF+x5WHj5FS2CRqCeRKJ5pI+R6XYo8eFO7TqC90NOPgaZ4 LCZ+Y2eyoug9Av/fN5XoSwibh21Q4+44diMhuLiZiYdGRzseTztubCF+OSrdT7z7O4IR c3v/jLZF5ZdOefx3wKXeXcDqg5Ajt0yptniqDdI8w2ulz2Dm9fFM1vOaKs2UJE3x3Fn0 j5iqHmAiYBWgkg2hmzxcbKL8JqMPZwkEG2Pz6oqlp9WYardW4A78XcolH3F5cfj8ek2s VZt9Vd4MoXigQAf6B61Sps2G5Wt5VXMbRT4mkiB38bofDBwSPV3Ft5yL1GdKGgows6m/ QoWA== X-Gm-Message-State: AOAM530de7rzXrP7zakRrnJXXnE38vtClyxgQFBVyajLQCcD/BXq1xiU CK2uDFvxI6WQ5S+mZwQIQupwo983MZkKLQXOyo8= X-Google-Smtp-Source: ABdhPJzCvDr9wny34TFs7UugIKmKrbkv6wJbHo0QxpY5ILB8bExIDhViHl1buOUplb6n5GCNmS2iPW3GAQXIq8nMbFE= X-Received: by 2002:a5d:841a:: with SMTP id i26mr5238589ion.144.1597331881723; Thu, 13 Aug 2020 08:18:01 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> In-Reply-To: From: Fabien Imbault Date: Thu, 13 Aug 2020 17:17:49 +0200 Message-ID: To: Justin Richer Cc: Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000660c0d05acc3cf44" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:18:05 -0000 --000000000000660c0d05acc3cf44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Without surprise, +1 to differentiate between the back-channel and the front-channel. On Thu, Aug 13, 2020 at 5:15 PM Justin Richer wrote: > Denis, I want to focus on one point here: > > In OAuth 2.0, the user consent is performed by the AS using an authorize > endpoint where the user consent is solicited and captured. > > Since a user, with no prior experience, shall first connect to a RS to > perform an operation, the user consent shall be performed by the RS, > instead of the AS. This means that we should define a "consent" endpoint > at the RS. > > > One of my goals with XYZ=E2=80=99s design was to be able to separate the > interaction with the user from the web-based flows for the delegation > protocol, and that aspect is enshrined in the GNAP charter as well. > > It points to the reality that there are two different aspects of the > traditional AS that we might need to talk about separately now. One deals > with delegation, issuing tokens, returning data directly to the client (n= ot > through a separate API, since that=E2=80=99s the RS), and other back-chan= nel stuff. > The other aspect deals with interacting with the user and/or resource > owner. > > We already saw bits of this in OAuth 2: the AS is defined by the pair of > the token endpoint and authorization endpoint, each filling the respectiv= e > roles above. What if we formally separate these? Strawman names: > > > Delegation Server (DS) - handles the back-channel stuff > > Interaction Server (IS) - handles the front-channel stuff > > > =E2=80=94 Justin > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000660c0d05acc3cf44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Without surprise,=C2=A0+1 to differentiate=C2=A0between th= e back-channel and the front-channel.

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 13, 2020 at 5:15 PM Justin= Richer <jricher@mit.edu> wrot= e:
Denis, I want to focus on one point here:
=
In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.<= /font>

One of my goals with XYZ=E2= =80=99s design was to be able to separate the interaction with the user fro= m the web-based flows for the delegation protocol, and that aspect is enshr= ined in the GNAP charter as well.

It points to the= reality that there are two different aspects of the traditional AS that we= might need to talk about separately now. One deals with delegation, issuin= g tokens, returning data directly to the client (not through a separate API= , since that=E2=80=99s the RS), and other back-channel stuff. The other asp= ect deals with interacting with the user and/or resource owner.=C2=A0
=

We already saw bits of this in OAuth 2: the AS is defin= ed by the pair of the token endpoint and authorization endpoint, each filli= ng the respective roles above. What if we formally separate these? Strawman= names:


Delegation Server (DS) - ha= ndles the back-channel stuff

Interaction Server (I= S) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000660c0d05acc3cf44-- From nobody Thu Aug 13 08:22:19 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 808A43A0D61 for ; Thu, 13 Aug 2020 08:22:17 -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 tIATjSpG28mp for ; Thu, 13 Aug 2020 08:22:15 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 609CC3A0D60 for ; Thu, 13 Aug 2020 08:22:15 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id w14so6629328ljj.4 for ; Thu, 13 Aug 2020 08:22:15 -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=2NBg5iIubdStm7S8wvvxyFsCzKiwF+OEd3P5yuZIIp4=; b=nKAMyBwbFxzY6cHfPUujfxDklWKto6/ByOG5RVUtq62sv66FWqxSBNek0j0SfQOa1T DS+hshstZNioThjKqCiiAufLow5+Ih3bIQIUrBhdSQA0oMDRYvpaWGl57yH6kDBsocKt dEeuZwMlX/I6EzCuNe00UDSGEXuYlt0xC6MhFuoAHwY6utLivNlieEBZ7dlgvqNz5iuE 8CZScVMpENrjny3IqF9Jwy38qOK7e8jIvs5zzUCB/BEwTzMcgYHbtNpcL4mUqhF5UoeO oSgydXwHZeNvqtmYb+y5Cuir1bPpUhes1WVaMvkre2OQNnkvLKFho7uP0+eW5MB0FezF ApQQ== 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=2NBg5iIubdStm7S8wvvxyFsCzKiwF+OEd3P5yuZIIp4=; b=MhF8Fe733E367Oz7o7oUVvBWLCmG/sANMsEoA/qYhU666U7U0HqYHl5fKelpjkNLMm +/BBDXhmEY56GKyGgE5JyZcpjJRvUhsTqfAvO8wGeRNzCPJpW6jngHChAOMP3RDcRobh /x8rcEzhCvVKyFpFtAiDPCDVdnmz3bcKmlEIsJsD+gdz7eSWZ2k1Rmp+Huk37A7Yr2cX CXMPTqyKlgLi8+mP6xc/hfbrYePMTUrjzqC5Ob2Wu82k8N2lEKNMGxNgKYObBnqG6ix9 Oxh0O0TeBpRlOHcxo6aqfdGbabddIA3aucsiVqp5IVqtcE+PZ/okZJduAp74hxEL8yXa 01Sw== X-Gm-Message-State: AOAM532i13veigLz9lDmQVrN7tZYD5+gcPy5EAMaP6DZn2oEikuq7ECR or7UPZNrlGC4ROIdXUoeV0YRObHXUyHsWHVpAH0= X-Google-Smtp-Source: ABdhPJwQXXFp8uYc9Insp4LTgblYmdSUL7EhnCdA6hqnLkDu4B9XZVwOIiMC2ztnRziolAdL9KATj9uiGUfztiyi24Q= X-Received: by 2002:a2e:b0db:: with SMTP id g27mr2417963ljl.69.1597332133041; Thu, 13 Aug 2020 08:22:13 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 08:21:36 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000060de0405acc3de98" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:22:18 -0000 --00000000000060de0405acc3de98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with clearly separating the GS interaction with the Client from the interaction with the User. I'm having a hard time viewing those as two different roles. They are two different interactions. Just as the client interaction with the AS is different from the client interaction with the GS. =E1=90=A7 On Thu, Aug 13, 2020 at 8:18 AM Fabien Imbault wrote: > Without surprise, +1 to differentiate between the back-channel and the > front-channel. > > On Thu, Aug 13, 2020 at 5:15 PM Justin Richer wrote: > >> Denis, I want to focus on one point here: >> >> In OAuth 2.0, the user consent is performed by the AS using an authorize >> endpoint where the user consent is solicited and captured. >> >> Since a user, with no prior experience, shall first connect to a RS to >> perform an operation, the user consent shall be performed by the RS, >> instead of the AS. This means that we should define a "consent" endpoint >> at the RS. >> >> >> One of my goals with XYZ=E2=80=99s design was to be able to separate the >> interaction with the user from the web-based flows for the delegation >> protocol, and that aspect is enshrined in the GNAP charter as well. >> >> It points to the reality that there are two different aspects of the >> traditional AS that we might need to talk about separately now. One deal= s >> with delegation, issuing tokens, returning data directly to the client (= not >> through a separate API, since that=E2=80=99s the RS), and other back-cha= nnel stuff. >> The other aspect deals with interacting with the user and/or resource >> owner. >> >> We already saw bits of this in OAuth 2: the AS is defined by the pair of >> the token endpoint and authorization endpoint, each filling the respecti= ve >> roles above. What if we formally separate these? Strawman names: >> >> >> Delegation Server (DS) - handles the back-channel stuff >> >> Interaction Server (IS) - handles the front-channel stuff >> >> >> =E2=80=94 Justin >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000060de0405acc3de98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with clearly separating the GS interaction with th= e Client from the interaction with the User.=C2=A0

I'= ;m having a hard time viewing those as two different roles. They are two di= fferent interactions. Just as the client interaction with the AS is differe= nt from the client interaction with the GS.
3D""=E1=90=A7

On Thu, Aug 13, 2020 at 8:18 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Without s= urprise,=C2=A0+1 to differentiate=C2=A0between the back-channel and the fro= nt-channel.

On Thu, Aug 13, 2020 at 5:15 PM Justin Richer <jricher@mit.edu> wrote:
Denis, I want to= focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.<= /font>

One of my goals with XYZ=E2= =80=99s design was to be able to separate the interaction with the user fro= m the web-based flows for the delegation protocol, and that aspect is enshr= ined in the GNAP charter as well.

It points to the= reality that there are two different aspects of the traditional AS that we= might need to talk about separately now. One deals with delegation, issuin= g tokens, returning data directly to the client (not through a separate API= , since that=E2=80=99s the RS), and other back-channel stuff. The other asp= ect deals with interacting with the user and/or resource owner.=C2=A0
=

We already saw bits of this in OAuth 2: the AS is defin= ed by the pair of the token endpoint and authorization endpoint, each filli= ng the respective roles above. What if we formally separate these? Strawman= names:


Delegation Server (DS) - ha= ndles the back-channel stuff

Interaction Server (I= S) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000060de0405acc3de98-- From nobody Thu Aug 13 08:27: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 D6C0F3A0DC4 for ; Thu, 13 Aug 2020 08:27:07 -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 fmlJxc10faR2 for ; Thu, 13 Aug 2020 08:27:05 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 B638D3A0DC2 for ; Thu, 13 Aug 2020 08:27:04 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id c15so3261034lfi.3 for ; Thu, 13 Aug 2020 08:27:04 -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=wKbI6B7RqxObM1DvhjBvM697bYBLMfDtLxikoMpuv4s=; b=sG8u25FdF8dcoKdHT7lj8frL5PobGgtZ3yDjbjYTg2UWax1tXNJODNcaISVon1PoqQ PkKwGNsNl3sqNmkTmuQmGDgdh8mYxuGzWM51QNdQX7z6Y+IMpaZ9rWYbkIXnvcEQNF9X i5pNccGPEMi+ndMeT/NG5+pJX0+mUmp+Hnjlg2GARzM7K970QcHGNUwhjNpCNH3MflLn /j05m5h9PD1u/BfONhcSyEJGENkKx1RG6F9PXa3WpMS+lPoUQU5bF/dU9+zGDsXG9xmL LeBBgOtRPmgKoualibrm2Dv+OOb7HVoVCAqqCinoDTTbhzG9OmffJuz7ovQgCO2wqIBz nofw== 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=wKbI6B7RqxObM1DvhjBvM697bYBLMfDtLxikoMpuv4s=; b=XmDcE0fDMx4XVn9fepbjYoRQq1yqjfHuP+lRvlsfEoJrcugsYjKv/cNhJgHHPzqLyn 02bYF4kzUHQLhF+8VZMwRBc8t1Xev8Bq7v0UgskBkwyetjaNWBTJz0wbz+cZw18tDpSg /Zoca5u61IWMbHtlxnoQ+Xsij52lIpZlujCY+Gs/NUv8LAMpWewpEd6VaPkMK7JIJ1z8 0AGHqcKVe4WxSlekQy9DvS76SX79r4T5YGUsImpLi9HxhWkse91IH8diALEqxJmYPlvJ FLGAHBlkMHsUku9dcBfbc9okmEH5Y1ubraBJfWB77jtq9fGUmQTG4B+IzHqHiwT483gf 1jbQ== X-Gm-Message-State: AOAM533shcV9PIw/qbrA5zrkO3ukQvtZ6nTWhmG6xXKOWIzPPhMVoQxQ cW10r6wXDD9q5TyKErma23bS7Oejtyu9kw2xLzk= X-Google-Smtp-Source: ABdhPJx95H/7JSBAjaAO1o3YXF/4XtWbTvVgqszr18ZyS5i+1FFYqHs826tdVOW6FNogo5E4tDHE/exW1hJmit067cA= X-Received: by 2002:a19:70c:: with SMTP id 12mr2482647lfh.207.1597332422588; Thu, 13 Aug 2020 08:27:02 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> In-Reply-To: <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> From: Dick Hardt Date: Thu, 13 Aug 2020 08:26:26 -0700 Message-ID: To: Justin Richer Cc: Tom Jones , Francis Pouatcha , Denis , Benjamin James Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a2fb8105acc3ef5d" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:27:08 -0000 --000000000000a2fb8105acc3ef5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes. I think it is useful to separate human interactions with software from software interactions with software. The latter we can standardize, the former we can call out as part of the overall process, but it is not something that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol. =E1=90=A7 On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: > It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure where = the objection > you=E2=80=99re raising comes from. > > Also, whatever roles we define here, whether software or human-ware, they > need to be related to the protocol. > > =E2=80=94 Justin > > On Aug 13, 2020, at 10:59 AM, Tom Jones > wrote: > > I strong object to the objectification of human users. It is way past tim= e > that the IETF becaume user oriented instead of web service oriented. > users are human in my language. > Peace ..tom > > > On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: > >> If defined as the party operating the client software, then the user is = a >> role. I believe this is more accurate and inclusive than the definition = you >> have proposed with the user as an entity. >> >> - Justin >> ________________________________________ >> From: Dick Hardt [dick.hardt@gmail.com] >> Sent: Tuesday, August 11, 2020 6:21 PM >> To: Francis Pouatcha >> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >> driving use case for the creation of OAuth) >> >> Hi Francis >> >> The user is an entity, not a role in the protocol in how I am defining >> roles, so steps (1) and (7) are confusing to me on what is happening. >> >> I also think that (2) could be an extension to GNAP, rather than part of >> the core protocol. >> >> >> >> >> >> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha > fpo@adorsys.de>> wrote: >> In this context, I suggest we pick some words to work with, and sharpen >> them as we move on, discover and map new use cases to the protocol. >> >> In this diagram from the original thread ( >> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw= /), >> I replaced the words: >> >> +-----------+ +--------------+ +----+ +----+ >> +---------------------+ >> | Requestor | | Orchestrator | | | | GS | | Resource >> Controller | >> | was | | was | | RS | | or | | was >> | >> | User | | Client | | | | AS | | Resource Owner >> | >> +-----------+ +--------------+ +----+ +----+ >> +---------------------+ >> |(1) ServiceRequest | | | | >> |---------------------->| | | | >> | |(2) ServiceIntent:AuthZChallenge | >> | |<---------->| | | >> | | | | | >> | |(3) AuthZRequest(AuthZChallenge) | >> | |------------------->| | >> | | | |(4) ConsentRequest:Grant >> | | | |<-------------->| >> | |(5) GrantAccess(AuthZ) | >> | |<-------------------| | >> | | | | | >> | |(6) ServiceRequest(AuthZ):ServiceResponse >> | |<---------->| | | >> |(7) ServiceResponse | | | | >> |<----------------------| | | | >> + + + + + >> >> The purpose of the GNAP protocol is to help negotiate access to a >> protected resource. It starts with a requestor delegating activity to an >> orchestrator. These are all roles, no entities. Let focus on mapping the >> use cases to the protocol roles and interactions so wwe can discover wha= t >> is missing. >> >> It seems cumbersome to use it in discussions as it is impossible to give >> the word "Client" a clear definition. >> >> We can mention in the final document, that the "Orchestrator" (or >> whatever word we finally use) plays the same role as the "Client" in oAu= th2. >> >> Best regards. >> /Francis >> >> >> >> >> >> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt > dick.hardt@gmail.com>> wrote: >> I agree with Justin. Redefining well used terms will lead to significant >> confusion. If we have a different role than what we have had in the past= , >> then that role should have a name not being used already in OAuth or OID= C. >> >> Given what we have learned, and my own experience explaining what a >> Client is, and is not, improving the definition for Client could prove >> useful. I am not suggesting the term be redefined, but clarified. >> >> For example, clarifying that a Client is a role an entity plays in the >> protocol, and that the same entity may play other roles at other times, = or >> some other language to help differentiate between "role" and "entity". >> >> /Dick >> [ >> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3= D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7 >> >> >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer > jricher@mit.edu>> wrote: >> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bette= r fit, but I=E2=80=99m >> not really in favor of taking an existing term and applying a completely >> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >> and come up with a new, more specific and accurate term for the role tha= n >> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diffe= rent. We did this >> in going from OAuth 1 to OAuth 2 already, moving from the >> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >> >> GNAP can do something similar, in my opinion. But what we can=E2=80=99t = do is >> ignore the fact that GNAP is going to be coming up in a world that is >> already permeated by OAuth 2 and its terminology. We don=E2=80=99t have= a blank >> slate to work with, but neither are we bound to use the same terms and >> constructs as before. It=E2=80=99s going to be a delicate balance! >> >> =E2=80=94 Justin >> >> On Aug 4, 2020, at 3:32 PM, Warren Parad > wparad@rhosys.ch>> wrote: >> >> I think that is fundamentally part of the question: >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion >> >> If we say that this document assumes OAuth2.0 terminology, then we shoul= d >> not change the meanings of any definition. If we are saying this superse= des >> or replaces what OAuth 2.0 creates, then we should pick the best word fo= r >> the job and ignore conflicting meanings from OAuth 2.0. I have a lot of >> first hand experience of industries "ruining words", and attempting to >> side-step the problem rather than redefining the word just confuses >> everyone as everyone forgets the original meaning as new documents come >> out, but the confusion with the use of a non-obvious word continues. >> >> Food for thought. >> - Warren >> >> [ >> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOs= W56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuI= m9GCeBRRzrSc8kWcUSNtuA >> ] >> >> Warren Parad >> Founder, CTO >> >> Secure your user data and complete your authorization architecture. >> Implement Authress. >> >> >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > kaduk@mit.edu>> wrote: >> Hi Denis, >> >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> > >> > Since you replied in parallel, I will make a response similar to the o= ne >> > I sent to Dick. >> > >> > > Hi Denis, >> > > >> > > I think there=E2=80=99s still a problem with the terminology in use = here. What >> > > you describe as RS2, which might in fact be an RS unto itself, is a >> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client o= f RS1/. What you >> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world, = but it is not at >> > > all the same as an OAuth client. I appreciate your mapping of the >> > > entities below, but it makes it difficult to hold a discussion if we >> > > aren=E2=80=99t using the same terms. >> > > >> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we c= an define >> > > our own terms. The bad news is that this is really hard to do. >> > > >> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new de= finitions, >> > > but we=E2=80=99ve got a chance to be more precise with how we define= things. >> > >> > In the ISO context, each document must define its own terminology. The >> > boiler plate for RFCs does not mandate a terminology or definitions >> section >> > but does not prevent it either. The vocabulary is limited and as long = as >> > we clearly define what our terms are meaning, we can re-use a term >> already >> > used in another RFC. This is also the ISO approach. >> >> Just because we can do something does not necessarily mean that it is a >> good idea to do so. We are clear that we are producing a protocol that = is >> conceptually (if not more strongly) related to OAuth 2.0, and reusing >> terms >> from OAuth 2.0 but with different definitions may lead to unnecessary >> confusion. If I understand correctly, a similar reasoning prompted Dick >> to >> use the term "GS" in XAuth, picking a name that was not already used in >> OAuth 2.0. >> >> -Ben >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> 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/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --000000000000a2fb8105acc3ef5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Tom's objection, and I agree with it, is that = humans don't interact in bits and bytes.=C2=A0

I thi= nk it is useful to separate human interactions with software from software = interactions with software. The latter we can standardize, the former we ca= n call out as part of the overall process, but it is not something that is = testable or required for interop, so I would argue human to software intera= ctions are NOT part of the protocol.

3D""= =E1=90=A7

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sur= e where the objection you=E2=80=99re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they = need to be related to the protocol.

=C2=A0=E2= =80=94 Justin

On Aug 13, 2020, a= t 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

=
I strong object to the objectification of human users. It = is way past time that the IETF becaume user oriented instead of web service= oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party opera= ting the client software, then the user is a role. I believe this is more a= ccurate and inclusive than the definition you have proposed with the user a= s an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a drivin= g use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining role= s, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of th= e core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen the= m as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOB= JqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+=C2=A0 +----+=C2=A0 +----= +=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator |=C2=A0 |=C2=A0 =C2=A0 |= =C2=A0 | GS |=C2=A0 | Resource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client= =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |=C2=A0 =C2= =A0 Resource Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+=C2=A0 +----+=C2=A0 +----= +=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =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) ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected= resource. It starts with a requestor delegating activity to an orchestrato= r. These are all roles, no entities. Let focus on mapping the use cases to = the protocol roles and interactions so wwe can discover what is missing.
It seems cumbersome to use it in discussions as it is impossible to give th= e word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or= whatever word we finally use) plays the same role as the "Client"= ; in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
I agree with Justin. Redefining well used terms will lead to significant co= nfusion. If we have a different role than what we have had in the past, the= n that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client = is, and is not, improving the definition for Client could prove useful. I a= m not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the prot= ocol, and that the same entity may play other roles at other times, or some= other language to help differentiate between "role" and "en= tity".

/Dick
[https://mailfoogae.a= ppspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=3Dzeroconten= t&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto= :jricher@mit.edu&g= t;> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better f= it, but I=E2=80=99m not really in favor of taking an existing term and appl= ying a completely new definition to it. In other words, I would sooner stop= using =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and a= ccurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meanin= g something completely different. We did this in going from OAuth 1 to OAut= h 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D= to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2= =80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2=80=9D on= its own but instead always qualifies it with =E2=80=9CAuthorization Server= =E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do = is ignore the fact that GNAP is going to be coming up in a world that is al= ready permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have= a blank slate to work with, but neither are we bound to use the same terms= and constructs as before. It=E2=80=99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should n= ot change the meanings of any definition. If we are saying this supersedes = or replaces what OAuth 2.0 creates, then we should pick the best word for t= he job and ignore conflicting meanings from OAuth 2.0. I have a lot of firs= t hand experience of industries "ruining words", and attempting t= o side-step the problem rather than redefining the word just confuses every= one as everyone forgets the original meaning as new documents come out, but= the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https= ://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A7= 4mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRR= zrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Impleme= nt Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<= ;mailto:Txauth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<= ;mailto:Txauth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<= ;mailto:TXAuth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<= ;mailto:TXAuth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth


--
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

--000000000000a2fb8105acc3ef5d-- From nobody Thu Aug 13 08:29:26 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 DBF263A0D4D for ; Thu, 13 Aug 2020 08:29:24 -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 HHT6IcsgjpBN for ; Thu, 13 Aug 2020 08:29:20 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 51FDA3A0DAA for ; Thu, 13 Aug 2020 08:29:18 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id v15so3243963lfg.6 for ; Thu, 13 Aug 2020 08:29:18 -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=jw/PzH2Ksjc9UjEHaIqHnwyq46uopEuo1RaX4V/592c=; b=bAp9/rZtM2s4JVW6NLt0x5Evjc1lYqRU6vvwlNK5rUeL1FbPCTmatqGtn8hY6m8zti kMKXDst0+4lkowHrh0CvfVQ/i/+xBAuwsNVFWfNzsj/DLcuKzn/TAImtyMwXiHMdAQaE SYsKZYltXT++ZLT2vpLuRsbxqL/rVl+QHbK23ikoy+Z42HlorGRA+Nmh0vb05wgB6sfM iFXgM82flCROW/y67Etk4bmcgxfYRFNkK1ZFWBGTYABkNSusUAIap7PIYY+PIoY/Wxav OHNAvao7x3tCXIyMoNAR6BordO57jChiUfdUxFpthOAY0wPOIkQJD6TkZn3ZvSjxE09i vV5g== 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=jw/PzH2Ksjc9UjEHaIqHnwyq46uopEuo1RaX4V/592c=; b=KjirdplY2BVg2BPwG8dZxlU5tSG8Azy/OvfNbPD1i7QReLuTeUYeM2Z6/vqVGUgSOk ua/ltn4J1An2qEVV3crcGnXbpz9wp27+GKJYFLQQj6BDnagm9bXnnH+JbEADRvLzznqX 9yw4vbpj17K5cMsX3utRkhsj0wb7kkzg+YuYc/K/BCDYYwVleJiRJELKeRvj+WsIKe0/ yH9pr4jeRXvaOKEPlIsCWUe2Zl8RmaBuouytGCgSRnKbmXmTk54CRvU9FwOMiitIbP17 QvqLQ0BMGHWiJ4FS/BDW0B1+aL2sNBX/hk2k0jIdRjNRD5nELa3tv6arjxFAGaR7HCcK 7xQw== X-Gm-Message-State: AOAM5324D7VGbT5bm0ZQtpXALe1sBGjvqqAMo6qU4s+hDbyNDJYhj272 zffSoPQljKETgVfeGQtDD/SGLn/xdOd0uziw+kB3TpN4 X-Google-Smtp-Source: ABdhPJx+Nrfzo+7sls3ktPy+6uHU+0W+4kFC793BG7954FvWdZaXt8HejERVwDdkU/lw26/3M/n1wKBo/+mm+qSIKWs= X-Received: by 2002:a19:8044:: with SMTP id b65mr2468328lfd.91.1597332555742; Thu, 13 Aug 2020 08:29:15 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 08:28:38 -0700 Message-ID: To: Denis Cc: Francis Pouatcha , Benjamin Kaduk , Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000092c0b905acc3f72d" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:29:25 -0000 --00000000000092c0b905acc3f72d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, we were discussing if a developer needs to read docs to use an API. If you want to introduce a new topic, would you start a new thread? =E1=90=A7 On Thu, Aug 13, 2020 at 7:04 AM Denis wrote: > Dick, > > A web browser is not a person. > > Denis > > PS1. You didn't reply to the second point of my email about a "consent" > endpoint at the RS. > > PS2. It would be better that you wait until you can use a real laptop to > respond and that you re-use the original message, > because the message you sent back is almost unreadable. > > The Client is not a person, it is software created by a developer. The > developer of the client is going to read the documentation for the RS to > program the Client. > > On Thu, Aug 13, 2020 at 6:47 AM Denis wrote: > >> >> >> >> >> >> >> >> >> >> >> Dick, >> >> >> >> >> >> >> >> I first jump on the >> >> following exchanges: >> >> >> >> >> >> >> [Dick] Most deployments today accomplish >> >> (2) by the developer reading RS documentation. I'm in favor >> >> of showing that step in an abstract diagram. >> >> >> [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag >> >> f=C3=B6rst=C3=A5r inte svenska. Jeg forst=C3=A5r ikke norsk. >> >> >> One of the goals is for any Client to access any >> >> RS without the need to read any documentation. >> >> >> [Dick]That is >> >> impractical. Most RSes today have resource specific APIs. >> >> The Client is either reading a standard API doc, or the >> >> resource specific API doc. >> >> >> >> >> >> >> >> >> I am not so sure >> >> that it is impractical. >> >> >> >> >> >> >> >> In 2012, Geert >> >> Jansen considered the possibility for complete auto-discovery >> >> by the API user, so that the API can be used by a human with a >> >> web browser, >> >> >> without any reference to external documentation. See the "Form >> >> Definition Language" in : >> >> https://restful-api-design.readthedocs.io/en/latest/forms.html >> >> >> >> >> >> >> >> >> In his view, forms >> >> need to specify three pieces of information: >> >> >> >> >> 1. How to contact the target >> >> and format the input. >> >> >> 2. A list of all available input fields. >> >> >> 3. A list of constraints with which the input fields must >> >> comply. >> >> >> >> >> Hence, >> >> in his view, the >> >> form consists of 3 parts: form metadata, field definitions, >> >> and constraints. >> >> >> >> >> >> >> >> What do you think ? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The second point on >> >> which I would like to insist is about the use of a "dialog >> >> box" for user interaction. This wording is used in RFC 6973. >> >> >> >> >> >> >> >> In OAuth 2.0, the user >> >> consent is performed by the AS using an authorize endpoint >> >> where the user consent is solicited and captured. >> >> >> >> >> >> >> >> Since a user, with no >> >> prior experience, shall first connect to a RS to perform an >> >> operation, the user consent >> >> shall be performed by the RS, >> >> >> instead of the >> >> AS. This means that we >> >> should define a "consent" endpoint at the RS. >> >> >> >> >> >> >> >> Denis >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> comments inline ... >> >> >> >> >> >> >> >> On Wed, Aug 12, 2020 at 7:14 >> >> AM Denis wrote: >> >> >> >> >> >>> >>> >>> >>> Hi Dick, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Francis, responses inline ... >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 11, >>> >>> 2020 at 3:37 PM Francis Pouatcha >>> >>> wrote: >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> Hello Dick, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Aug >>>> >>>> 11, 2020 at 6:22 PM Dick Hardt >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Hi Francis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The user is an entity, not a role in >>>>> >>>>> the protocol in how I am defining roles, >>>>> >>>>> so steps (1) and (7) are confusing to me >>>>> >>>>> on what is happening. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> "Requestor" is the role (*was* >>>> >>>> User). So the UML participant refers to the >>>> >>>> role "Requestor" >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> I still don't understand what is happening in >>> >>> (1) and (7) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> Would you provide more explanation? >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I also think that (2) could be an >>>>> >>>>> extension to GNAP, rather than part of >>>>> >>>>> the core protocol. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> If you make it an extension, you hide. It >>>> >>>> shall rather be an optional, integral part >>>> >>>> of the protocol. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Most deployments today accomplish (2) by the >>> >>> developer reading RS documentation. I'm in favor >>> >>> of showing that step in an abstract diagram. >>> >>> >>> >>> >>> >>> >>> >>> >>> [Denis] Really by reading RS documentation ? Non capisco l'italiano. Ja= g >>> f=C3=B6rst=C3=A5r inte svenska. Jeg >>> >>> forst=C3=A5r ikke norsk. >>> >>> >>> One of the goals is for any >>> >>> Client to access any RS without the need >>> >>> to read any documentation. >>> >>> >>> >>> >>> >> >> >> >> >> >> >> That is impractical. Most RSes today have resource >> >> specific APIs. The Client is either reading a standard API >> >> doc, or the resource specific API doc. >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> But it is not clear to me what the requirements >>> >>> for (2), and they may vary radically across use >>> >>> cases, so putting it in the core document seems to >>> >>> be getting ahead of ourselves. >>> >>> >>> >>> >>> >>> >>> >>> >>> [Denis] I can >>> >>> only reinsist on earlier explanations given about >>> >>> the Client-server use cases built along "Privacy by >>> >>> Design" since they are fundamental. >>> >>> >>> >>> >>> >> >> I agree with the principle of "Privacy by Design". There >> >> are LOTS of details in how to do what you outline below, and >> >> I expect they will be radically different across use cases, >> >> which is why I don't think it fits into the core document, >> >> but I do agree with calling it out in the abstract. When I >> >> publish an updated draft, let me know what you think then. >> >> >> >> >> >> >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Taking into >>> >>> consideration both the "data minimization" >>> >>> principle and the "user participation" principle >>> >>> when a user first authenticates to a RS leads to >>> >>> the following: >>> >>> >>> >>> >>> >>> >>> >>> >>> 1) When >>> >>> accessing a RS for the first time, the user should >>> >>> be informed of the authentication means proposed >>> >>> by the RS. The user should be able to use a dialog >>> >>> box >>> >>> >>> where some choices are presented by the RS. The >>> >>> user should be able to locally make his own >>> >>> choices and to indicate his consent to its Client. >>> >>> >>> 2) When a user chooses to perform one >>> >>> operation on a RS, the RS should limit the data to >>> >>> be collected from the user to only what is >>> >>> strictly necessary >>> >>> >>> to perform that operation. That data consists of >>> >>> specific types of attributes that need to be >>> >>> guaranteed by one or more ASs. The user should be >>> >>> able >>> >>> >>> to use a dialog box where some ASs choices are >>> >>> proposed by the RS. The user should be able to >>> >>> locally make his own choices and to indicate >>> >>> >>> his consent to its Client. >>> >>> >>> >>> >>> >>> >>> >>> >>> It is >>> >>> important to notice that the choices that will be >>> >>> proposed to a user may depend upon previous >>> >>> personal information voluntarily released by that >>> >>> user. >>> >>> >>> This means >>> >>> that the choices proposed by the RS may be >>> >>> tailored for the user. Furthermore, the proposed >>> >>> choices may only be disclosed to already >>> >>> authenticated users. >>> >>> >>> >>> >>> Denis >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> In some open banking designs, >>>> >>>> >>>> - the "Orchestrator/Negotiator/Client" >>>> >>>> will not know the AS to talk to unless the >>>> >>>> call (2). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Have you put these use cases in the wiki? >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> - the request (2) might result in an >>>> >>>> exemption, meaning no need for further >>>> >>>> authorization, allowing to skip (3, 4, 5) >>>> >>>> and even (6). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Agreed. >>> >>> >>> >>> >>> >>> >>> >>> >>> =E1=90=A7 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> =E1=90=A7 >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >> >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000092c0b905acc3f72d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis, we were discussing if a developer needs to read = docs to use an API.

If you want to introduce a new topic= , would you start a new thread?


3D""=E1=90=A7
On Thu, Aug 13, 2020 at 7:04 AM Denis <denis.ietf@free.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> =20 =20 =20
Dick,

A web browser is not a person.

Denis

PS1. You didn't reply to the second point of my email about a "consent= " endpoint at the RS.

PS2. It would be better that you wait until you can use a real laptop to respond and that you re-use the original message,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 because the me= ssage you sent back is almost unreadable.

=20
The Client is not a person, it is software created by a developer. The developer of the client is going to read the documentation for the RS to program the Client.

On Thu, Aug 13, 2020 at 6:4= 7 AM Denis <denis.ietf@free.fr> wrote:










Dick,







I first jump on the

following exchanges:






[Dick] Most deployments today accomplish

(2) by the developer reading RS documentation. I'= m in favor

of showing that step in an abstract diagram. <= /div>

[Denis] Really by reading RS documentation ? = Non capisco l'italiano. Jag

f=C3=B6rst=C3=A5r inte svenska. Jeg forst=C3=A5r ikke norsk.


One of the goals is for any Client to access any

RS without the need to read any documentation.



[Dick]That is

impractical. Most RSes today have resource specific APIs.

The Client is either reading a standard API doc, or the

resource specific API doc.








I am not so sure

that it is impractical.







In 2012, Geert

Jansen considered the possibility for complete auto-discovery

by the API user, so that the API can be used by a human with a

web browser,


without any reference to external documentation. See the "Form

Definition Language" in :

https:/= /restful-api-design.readthedocs.io/en/latest/forms.html








In his view, forms

need to specify three pieces of information:




1.=C2=A0=C2=A0=C2=A0 How to contact the target

and format the input.


2.=C2=A0=C2=A0=C2=A0 A list of all available input fi= elds.


3.=C2=A0=C2=A0=C2=A0 A list of constraints with which= the input fields must

comply.




= Hence,

in his view, the

form consists of 3 parts: form metadata, field definitions,

and constraints.







What do you think ?














The second point on

which I would like to insist is about the use of a "dialog

box" for user interaction. This wording is used = in RFC 6973.







In OAuth 2.0, the user

consent is performed by the AS using an authorize endpoint

where the user consent is solicited and captured.







Since a user, with no

prior experience, shall first connect to a RS to perform an

operation, the user consent

shall be performed by the RS,


instead = of the

AS. This means that we

should define a "consent" endpoint at the R= S.







Denis=




=



















comments inline ...=C2=A0







On Wed, Aug 12, 2020 at 7:14

AM Denis <denis.ietf@free.fr> wrote:








Hi Dick,











Hi Francis, responses inline ...=C2=A0






On Tue, Aug 11,

2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de>

wrote:








Hello Dick,







O= n Tue, Aug

11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com>

wrote:






Hi Francis






The user is an entity, not a role in

the protocol in how I am defining roles,

so steps (1) and (7) are confusing to me

on what is happening.






"Requestor" is the role = (was

User). So the UML participant refers=C2=A0to the

role "Requestor"













I still don't understand what is happening in

(1) and (7)

















Would you provide more explanation?


=C2=A0














=C2=A0
























I also think that (2) could be an

extension to GNAP, rather than part of

the core protocol.






If you make it an extension, you hide. It

shall rather be an optional, integral part

of the protocol.













Most deployments today accomplish (2) by the

developer reading RS documentation. I'm in favor

of showing that step in an abstract diagram.








[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag f=C3=B6rst=C3=A5r inte svens= ka. Jeg

forst=C3=A5r ikke norsk.



= One of the goals is for any

Client to access any RS without the need

to read any documentation.












That is impractical. Most RSes today have resource

specific APIs. The Client is either reading a standard API

doc, or the resource specific API doc.


=C2=A0












But it is not clear to me what the requirements

for (2), and they may vary radically across use

cases, so putting it in the core document seems to

be getting ahead of ourselves.








[Denis] I can

only reinsist on earlier explanations given about

the Client-server use cases built along "Privacy by

Design" since they are fundamental.







I agree with the principle of "Privacy by Design". There

are LOTS of details in how to do what you outline below, and

I expect they will be radically different across use cases,

which is why I don't think it fits into the core document,

but I do agree with calling it out in the abstract. When I

publish an updated draft, let me know what you think then.







=C2=A0













Taking into

consideration both the "data minimization"

principle and the "user participation&= quot; principle

when a user first authenticates to a RS leads to

the following:









1) When

accessing a RS for the first time, the user should

be informed of the authentication means proposed

by the RS. The user should be able to use a dialog

box


where some choices are presented by the RS. The

user should be able to locally make his own

choices and to indicate his consent to its Client.



2) When a user chooses to perform one

operation on a RS, the RS should limit the data to

be collected from the user to only what is

strictly necessary


to perform that operation. That data consists of

specific types of attributes that need to be

guaranteed by one or more ASs. The user should be

able


to use a dialog box where some ASs choices are

proposed by the RS. The user should be able to

locally make his own choices and to indicate


his consent to its Client.







It is

important to notice that the choices that will be

proposed to a user may depend upon previous

personal information voluntarily released by that

user.


This means

that the choices proposed by the RS may be

tailored for the user. Furthermore, the proposed

choices may only be disclosed to already
authenticated users.





Denis=









=C2=A0








In some open banking designs,=C2= =A0


- the "Orchestrator/Negotiator/Client&= quot;

will not know the AS to talk to unless the

call (2).













Have you put these use cases in the wiki?


=C2=A0








- the request (2) might result in an

exemption, meaning no need for further

authorization, allowing to skip (3, 4, 5)

and even (6).













Agreed.








=E1=90=A7
















=E1=90=A7













--

TXAuth mailing list

TXAuth@iet= f.org

https://www.ietf.org/mailman/listinfo/txauth=


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000092c0b905acc3f72d-- From nobody Thu Aug 13 08:33: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 D95943A0DE6 for ; Thu, 13 Aug 2020 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4GMks48gdqDt for ; Thu, 13 Aug 2020 08:33:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DB03A0DE5 for ; Thu, 13 Aug 2020 08:33:06 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DFX1Tq032551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 11:33:02 -0400 From: Justin Richer Message-Id: <08DEE9CF-F828-4221-AD51-B10AA1B2E9F2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B67FF51B-4859-4F04-838C-A7393CC263E1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 11:33:01 -0400 In-Reply-To: Cc: Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk , Dick Hardt To: Fabien Imbault References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:33:09 -0000 --Apple-Mail=_B67FF51B-4859-4F04-838C-A7393CC263E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A point I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D = isn=E2=80=99t going to exist for a lot of systems anymore, where = interaction happens through an app or communication happens through some = separate communication fabric. So there are cases, just like in OAuth 2, = where there=E2=80=99s only a =E2=80=9Cback channel=E2=80=9D and the = other aspect of the AS never comes into play. =E2=80=94 Justin > On Aug 13, 2020, at 11:17 AM, Fabien Imbault = wrote: >=20 > Without surprise, +1 to differentiate between the back-channel and the = front-channel. >=20 > On Thu, Aug 13, 2020 at 5:15 PM Justin Richer > wrote: > Denis, I want to focus on one point here: >=20 >> In OAuth 2.0, the user consent is performed by the AS using an = authorize endpoint where the user consent is solicited and captured. >>=20 >> Since a user, with no prior experience, shall first connect to a RS = to perform an operation, the user consent shall be performed by the RS,=20= >> instead of the AS. This means that we should define a "consent" = endpoint at the RS. >=20 > One of my goals with XYZ=E2=80=99s design was to be able to separate = the interaction with the user from the web-based flows for the = delegation protocol, and that aspect is enshrined in the GNAP charter as = well. >=20 > It points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner.=20 >=20 > We already saw bits of this in OAuth 2: the AS is defined by the pair = of the token endpoint and authorization endpoint, each filling the = respective roles above. What if we formally separate these? Strawman = names: >=20 >=20 > Delegation Server (DS) - handles the back-channel stuff >=20 > Interaction Server (IS) - handles the front-channel stuff >=20 >=20 > =E2=80=94 Justin >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_B67FF51B-4859-4F04-838C-A7393CC263E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = point I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D = isn=E2=80=99t going to exist for a lot of systems anymore, where = interaction happens through an app or communication happens through some = separate communication fabric. So there are cases, just like in OAuth 2, = where there=E2=80=99s only a =E2=80=9Cback channel=E2=80=9D and the = other aspect of the AS never comes into play.

 =E2=80=94 Justin

On Aug 13, 2020, at 11:17 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Without surprise, +1 to = differentiate between the back-channel and the = front-channel.

On Thu, Aug 13, 2020 at 5:15 PM Justin = Richer <jricher@mit.edu> wrote:
Denis, I want to focus on one point here:

In OAuth 2.0, the = user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the = user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the = RS.

One = of my goals with XYZ=E2=80=99s design was to be able to separate the = interaction with the user from the web-based flows for the delegation = protocol, and that aspect is enshrined in the GNAP charter as = well.

It = points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner. 

We already saw bits of this in OAuth 2: = the AS is defined by the pair of the token endpoint and authorization = endpoint, each filling the respective roles above. What if we formally = separate these? Strawman names:


Delegation Server (DS) - handles the back-channel = stuff

Interaction Server (IS) - handles the front-channel = stuff


 =E2=80=94 Justin

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

= --Apple-Mail=_B67FF51B-4859-4F04-838C-A7393CC263E1-- From nobody Thu Aug 13 08:34:48 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 3F0483A0D7E for ; Thu, 13 Aug 2020 08:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 G22z5-DPhgo9 for ; Thu, 13 Aug 2020 08:34:44 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 77BA63A0D7C for ; Thu, 13 Aug 2020 08:34:44 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id r13so1470765iln.0 for ; Thu, 13 Aug 2020 08:34:44 -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=/6tyUH1O4+MNNdQA77rbDpau0hcdLDTpE1SDud2r2PE=; b=vHCbPPnjRmSUW7ycgpPSjjPlYOM+CvCJe9cSCM+jkddRS8diCQGwqYWsELHUY4qoRb uLOuYPdVpgfWWkkO9add/ov+eahXXxdu/tANFxc77VZmnZatcOEJEJqXEO6VhHJRfeec 2j/3vX/Az4+fBGJt3dJESYGAqKj2JYJ+RI04I5naxmveLiyXQG2PnHIUcIHULDjnmCT+ r+88N7CW7nhQOfY57/AGn8iAahvCf+8RVJJ72VkdQklrScRRUku6B9ezcapczEaGTCv4 kQynZXIBtlSD6O7Z3VmtyFO7jCiUL4qWo9GcLQfiQcALjU9LMRcmZZM+LrNhz8IQttsk X1yQ== 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=/6tyUH1O4+MNNdQA77rbDpau0hcdLDTpE1SDud2r2PE=; b=Tf3U4xk/hOgk7vaA7lTZkqQcBrhQ9jLVitg5DnJFlmmr9DQnFb3DlZH5deOmpa/ZnO LpLT3bfSCfo+i7LasWQruAwcsjpdbKq4yEtCmopESmOYEkd1+JrCFbtBWMo2apGdxhAb qWYm0cxvjTsEi7/slPFBDh5J1Y8zP7TNDCJY0T3Dsk33SS1YO/ASWG/2XbKadMd2IH8O 1zCQ0SKfN3Km3nm0U2wzDt+dsHp1w/TVH1B3Lj00oh/giBOXrKYPTXXLLAJVPM/KXAJy VbtQ8xpJGuUoypxMHFAkifBcID1ysJFKPqQbf3DpJxbzN9zhN9nMA582atCHm+JsnuR0 sKEQ== X-Gm-Message-State: AOAM532Oh8VqI2feISD4MniTWDNM8vAxZ7X4qenE8ufzc574f+cT7pS8 ba/tn7Bn6cvfq99Upqu7cMCAfm+bgU/Z8+DW/u0= X-Google-Smtp-Source: ABdhPJzMr8CZRsdrnPrlQEdmicW1waKMBRascPOqgNekCwnZN7+ZDthEutI+nJc0h+I7xtElTEdoE0ELoknLyidgs4o= X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr4848393ils.188.1597332881310; Thu, 13 Aug 2020 08:34:41 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <08DEE9CF-F828-4221-AD51-B10AA1B2E9F2@mit.edu> In-Reply-To: <08DEE9CF-F828-4221-AD51-B10AA1B2E9F2@mit.edu> From: Fabien Imbault Date: Thu, 13 Aug 2020 17:34:29 +0200 Message-ID: To: Justin Richer Cc: Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000fa882105acc40a3d" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:34:46 -0000 --000000000000fa882105acc40a3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed. On Thu, Aug 13, 2020 at 5:33 PM Justin Richer wrote: > A point I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D isn= =E2=80=99t going to exist > for a lot of systems anymore, where interaction happens through an app or > communication happens through some separate communication fabric. So ther= e > are cases, just like in OAuth 2, where there=E2=80=99s only a =E2=80=9Cba= ck channel=E2=80=9D and > the other aspect of the AS never comes into play. > > =E2=80=94 Justin > > On Aug 13, 2020, at 11:17 AM, Fabien Imbault > wrote: > > Without surprise, +1 to differentiate between the back-channel and the > front-channel. > > On Thu, Aug 13, 2020 at 5:15 PM Justin Richer wrote: > >> Denis, I want to focus on one point here: >> >> In OAuth 2.0, the user consent is performed by the AS using an authorize >> endpoint where the user consent is solicited and captured. >> >> Since a user, with no prior experience, shall first connect to a RS to >> perform an operation, the user consent shall be performed by the RS, >> instead of the AS. This means that we should define a "consent" endpoint >> at the RS. >> >> >> One of my goals with XYZ=E2=80=99s design was to be able to separate the >> interaction with the user from the web-based flows for the delegation >> protocol, and that aspect is enshrined in the GNAP charter as well. >> >> It points to the reality that there are two different aspects of the >> traditional AS that we might need to talk about separately now. One deal= s >> with delegation, issuing tokens, returning data directly to the client (= not >> through a separate API, since that=E2=80=99s the RS), and other back-cha= nnel stuff. >> The other aspect deals with interacting with the user and/or resource >> owner. >> >> We already saw bits of this in OAuth 2: the AS is defined by the pair of >> the token endpoint and authorization endpoint, each filling the respecti= ve >> roles above. What if we formally separate these? Strawman names: >> >> >> Delegation Server (DS) - handles the back-channel stuff >> >> Interaction Server (IS) - handles the front-channel stuff >> >> >> =E2=80=94 Justin >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --000000000000fa882105acc40a3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed.

On Thu, Aug 13, 2020 at 5:33 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
A point I forgot to make below: the =E2=80=9Cfront channel= =E2=80=9D isn=E2=80=99t going to exist for a lot of systems anymore, where = interaction happens through an app or communication happens through some se= parate communication fabric. So there are cases, just like in OAuth 2, wher= e there=E2=80=99s only a =E2=80=9Cback channel=E2=80=9D and the other aspec= t of the AS never comes into play.

=C2=A0=E2=80=94 Justi= n

On Aug 13, 2020, at 11:17 AM, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

Without surprise,=C2=A0+1 to differentiate=C2=A0between the back-channel = and the front-channel.

On Thu, Aug 13, 2020 at 5:15 PM Justin Richer <jricher@mit.edu> w= rote:
Denis= , I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.<= /font>

One of my goals with XYZ=E2= =80=99s design was to be able to separate the interaction with the user fro= m the web-based flows for the delegation protocol, and that aspect is enshr= ined in the GNAP charter as well.

It points to the= reality that there are two different aspects of the traditional AS that we= might need to talk about separately now. One deals with delegation, issuin= g tokens, returning data directly to the client (not through a separate API= , since that=E2=80=99s the RS), and other back-channel stuff. The other asp= ect deals with interacting with the user and/or resource owner.=C2=A0
=

We already saw bits of this in OAuth 2: the AS is defin= ed by the pair of the token endpoint and authorization endpoint, each filli= ng the respective roles above. What if we formally separate these? Strawman= names:


Delegation Server (DS) - ha= ndles the back-channel stuff

Interaction Server (I= S) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin

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

--000000000000fa882105acc40a3d-- From nobody Thu Aug 13 08:41:17 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 2FF693A0DB3 for ; Thu, 13 Aug 2020 08:41:16 -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 bOt6NPeJj39D for ; Thu, 13 Aug 2020 08:41:14 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 1CFBC3A0DAD for ; Thu, 13 Aug 2020 08:41:13 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t6so6672180ljk.9 for ; Thu, 13 Aug 2020 08:41:13 -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=HmJYf/c+aIeBqlqULEgJDZokKVt9ckeStoctnXyH7zQ=; b=uvalEiUDD+RaDcAZck47Tb0Q4btbt3DbYCJ44r9x7Vuu5C+LZ016MQm1W06Btl3HS3 Xv+ytdQ3l+PRg5Fv5YSURXD6jtccsQ+ggUeLXlPeySeIB5RQma6SQPrMSi7xXGRmMOoN 3ggU6L0HD6O4XIM0+hyWXJuGv/QprR0aPHmfIexMVI+juZ4JA8AuZj+F3ob8DlnDzlL4 DQWr6bqnAHCFR51Qx8JKirzT4FqrlMhDNRPgRIqYnHOVEqrwXtuX8Cf0+q09uwSFpc7G ULcH9vtyR9Ip2MoV3mGGSqL+5a63rntThEIiBcyuR2D6EE7ImaSaspnKsvBbNxyM2KRR WjtQ== 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=HmJYf/c+aIeBqlqULEgJDZokKVt9ckeStoctnXyH7zQ=; b=gYTWFXxU3ji3C0Y007mBxpOinf6o9fyp5PH9ZGMwgsPof9KcBxxuLKRhwLD1IOz/J3 s0PTpGdOSTm3wg0O/Vryzb7HUn/B2pM7k57AExoY/frr0s85pygpw/q0EJoQoGHj3uYr liVgF8a0Ztnq6uPIlhzigsvkDOtnf4mnNqOKSiD+5HNnGVVlWqAg9EMBtpsNzHW7FAvS pwq/mBJirP1eSD69JmxJQ5g4jAZCUevypKoTljLwE49FemB2pMtRVqEwYSkHIYdoh7VM uotxnIPIxMyCn5K6DjlL2Xn4M0+dIcG41jucuBsqMisxBdDz19FZmJhRhXHP/Ah4IedV 5SMA== X-Gm-Message-State: AOAM530lYG+8qSutEYF3yrWSJpfjoU/KdUp0thqtkAHur7wi8mDfJI91 kLqHNpM267J0Rf4rVGvphpAWWcZcN86AL3GvO8A= X-Google-Smtp-Source: ABdhPJxHGAEXogN+GtLT5e7fft/C14M9IT9NfsSIgB3x9qBy3YYd3owddsq8yGerNAu2gzEr+7v/jYp6sP0fYjQCWAA= X-Received: by 2002:a2e:a16f:: with SMTP id u15mr2502931ljl.5.1597333271874; Thu, 13 Aug 2020 08:41:11 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <08DEE9CF-F828-4221-AD51-B10AA1B2E9F2@mit.edu> In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 08:40:35 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000004211a305acc4223f" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:41:16 -0000 --0000000000004211a305acc4223f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've often thought of front channel as an interaction visible to the user, and back channel as being between two software systems, in this case, the client and GS. Consent from the user is the front channel, independent of how the user gets to the GS, or if an app is part of the GS, or is the GS. =E1=90=A7 On Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault wrote: > Indeed. > > On Thu, Aug 13, 2020 at 5:33 PM Justin Richer wrote: > >> A point I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D isn= =E2=80=99t going to exist >> for a lot of systems anymore, where interaction happens through an app o= r >> communication happens through some separate communication fabric. So the= re >> are cases, just like in OAuth 2, where there=E2=80=99s only a =E2=80=9Cb= ack channel=E2=80=9D and >> the other aspect of the AS never comes into play. >> >> =E2=80=94 Justin >> >> On Aug 13, 2020, at 11:17 AM, Fabien Imbault >> wrote: >> >> Without surprise, +1 to differentiate between the back-channel and the >> front-channel. >> >> On Thu, Aug 13, 2020 at 5:15 PM Justin Richer wrote: >> >>> Denis, I want to focus on one point here: >>> >>> In OAuth 2.0, the user consent is performed by the AS using an authoriz= e >>> endpoint where the user consent is solicited and captured. >>> >>> Since a user, with no prior experience, shall first connect to a RS to >>> perform an operation, the user consent shall be performed by the RS, >>> instead of the AS. This means that we should define a "consent" >>> endpoint at the RS. >>> >>> >>> One of my goals with XYZ=E2=80=99s design was to be able to separate th= e >>> interaction with the user from the web-based flows for the delegation >>> protocol, and that aspect is enshrined in the GNAP charter as well. >>> >>> It points to the reality that there are two different aspects of the >>> traditional AS that we might need to talk about separately now. One dea= ls >>> with delegation, issuing tokens, returning data directly to the client = (not >>> through a separate API, since that=E2=80=99s the RS), and other back-ch= annel stuff. >>> The other aspect deals with interacting with the user and/or resource >>> owner. >>> >>> We already saw bits of this in OAuth 2: the AS is defined by the pair o= f >>> the token endpoint and authorization endpoint, each filling the respect= ive >>> roles above. What if we formally separate these? Strawman names: >>> >>> >>> Delegation Server (DS) - handles the back-channel stuff >>> >>> Interaction Server (IS) - handles the front-channel stuff >>> >>> >>> =E2=80=94 Justin >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> --0000000000004211a305acc4223f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've often thought of front channel as an interaction = visible to the user, and back channel as being between two software systems= , in this case, the client and GS.

Consent from the user= is the front channel, independent of how the user gets to the GS, or if an= app is part of the GS, or is the GS.
3D""=E1=90=A7<= /div>
O= n Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Indeed.
On Thu, = Aug 13, 2020 at 5:33 PM Justin Richer <jricher@mit.edu> wrote:
A point I forgot to make below: the= =E2=80=9Cfront channel=E2=80=9D isn=E2=80=99t going to exist for a lot of = systems anymore, where interaction happens through an app or communication = happens through some separate communication fabric. So there are cases, jus= t like in OAuth 2, where there=E2=80=99s only a =E2=80=9Cback channel=E2=80= =9D and the other aspect of the AS never comes into play.

=C2=A0=E2=80=94 Justin

On Aug = 13, 2020, at 11:17 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= br>
Without surprise,=C2=A0+1 to differentiate=C2=A0be= tween the back-channel and the front-channel.

On Thu, Aug 13, 2020 at 5:15 P= M Justin Richer <jr= icher@mit.edu> wrote:
Denis, I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.<= /font>

One of my goals with XYZ=E2= =80=99s design was to be able to separate the interaction with the user fro= m the web-based flows for the delegation protocol, and that aspect is enshr= ined in the GNAP charter as well.

It points to the= reality that there are two different aspects of the traditional AS that we= might need to talk about separately now. One deals with delegation, issuin= g tokens, returning data directly to the client (not through a separate API= , since that=E2=80=99s the RS), and other back-channel stuff. The other asp= ect deals with interacting with the user and/or resource owner.=C2=A0
=

We already saw bits of this in OAuth 2: the AS is defin= ed by the pair of the token endpoint and authorization endpoint, each filli= ng the respective roles above. What if we formally separate these? Strawman= names:


Delegation Server (DS) - ha= ndles the back-channel stuff

Interaction Server (I= S) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin

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

--0000000000004211a305acc4223f-- From nobody Thu Aug 13 08:52:17 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 1B8B33A0DFF for ; Thu, 13 Aug 2020 08:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WIGNwLl4Pa74 for ; Thu, 13 Aug 2020 08:52:14 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5983A0DFC for ; Thu, 13 Aug 2020 08:52:13 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DFq94U007788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 11:52:09 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0F40587A-66B2-4AB0-8427-5B79337819E7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 11:52:08 -0400 In-Reply-To: Cc: Fabien Imbault , Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk To: Dick Hardt References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <08DEE9CF-F828-4221-AD51-B10AA1B2E9F2@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:52:16 -0000 --Apple-Mail=_0F40587A-66B2-4AB0-8427-5B79337819E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s true when the front channel (redirects between parties) = is used as the method for interaction, but the point I was making is = that that method isn=E2=80=99t going to be the only way that interaction = happens. I don=E2=80=99t think it=E2=80=99s helpful to conflate other = interaction mechanisms that don=E2=80=99t use redirections with URIs and = query parameters as =E2=80=9Cfront channel=E2=80=9D here. The security = models and surrounding assumptions are very different.=20 =E2=80=94 Justin > On Aug 13, 2020, at 11:40 AM, Dick Hardt wrote: >=20 > I've often thought of front channel as an interaction visible to the = user, and back channel as being between two software systems, in this = case, the client and GS. >=20 > Consent from the user is the front channel, independent of how the = user gets to the GS, or if an app is part of the GS, or is the GS. > =E1=90=A7 >=20 > On Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault = > wrote: > Indeed. >=20 > On Thu, Aug 13, 2020 at 5:33 PM Justin Richer > wrote: > A point I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D = isn=E2=80=99t going to exist for a lot of systems anymore, where = interaction happens through an app or communication happens through some = separate communication fabric. So there are cases, just like in OAuth 2, = where there=E2=80=99s only a =E2=80=9Cback channel=E2=80=9D and the = other aspect of the AS never comes into play. >=20 > =E2=80=94 Justin >=20 >> On Aug 13, 2020, at 11:17 AM, Fabien Imbault = > wrote: >>=20 >> Without surprise, +1 to differentiate between the back-channel and = the front-channel. >>=20 >> On Thu, Aug 13, 2020 at 5:15 PM Justin Richer > wrote: >> Denis, I want to focus on one point here: >>=20 >>> In OAuth 2.0, the user consent is performed by the AS using an = authorize endpoint where the user consent is solicited and captured. >>>=20 >>> Since a user, with no prior experience, shall first connect to a RS = to perform an operation, the user consent shall be performed by the RS,=20= >>> instead of the AS. This means that we should define a "consent" = endpoint at the RS. >>=20 >> One of my goals with XYZ=E2=80=99s design was to be able to separate = the interaction with the user from the web-based flows for the = delegation protocol, and that aspect is enshrined in the GNAP charter as = well. >>=20 >> It points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner.=20 >>=20 >> We already saw bits of this in OAuth 2: the AS is defined by the pair = of the token endpoint and authorization endpoint, each filling the = respective roles above. What if we formally separate these? Strawman = names: >>=20 >>=20 >> Delegation Server (DS) - handles the back-channel stuff >>=20 >> Interaction Server (IS) - handles the front-channel stuff >>=20 >>=20 >> =E2=80=94 Justin >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_0F40587A-66B2-4AB0-8427-5B79337819E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s true when the front channel (redirects between = parties) is used as the method for interaction, but the point I was = making is that that method isn=E2=80=99t going to be the only way that = interaction happens. I don=E2=80=99t think it=E2=80=99s helpful to = conflate other interaction mechanisms that don=E2=80=99t use = redirections with URIs and query parameters as =E2=80=9Cfront channel=E2=80= =9D here. The security models and surrounding assumptions are very = different. 

 =E2=80=94 Justin

On Aug = 13, 2020, at 11:40 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

I've often thought of front = channel as an interaction visible to the user, and back channel as being = between two software systems, in this case, the client and GS.

Consent from the user is = the front channel, independent of how the user gets to the GS, or if an = app is part of the GS, or is the GS.
3D""=E1=90=A7

On Thu, Aug = 13, 2020 at 8:34 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Indeed.

On Thu, Aug 13, 2020 at 5:33 PM Justin = Richer <jricher@mit.edu> wrote:
A point I = forgot to make below: the =E2=80=9Cfront channel=E2=80=9D isn=E2=80=99t = going to exist for a lot of systems anymore, where interaction happens = through an app or communication happens through some separate = communication fabric. So there are cases, just like in OAuth 2, where = there=E2=80=99s only a =E2=80=9Cback channel=E2=80=9D and the other = aspect of the AS never comes into play.

 =E2=80=94 Justin

On Aug 13, 2020, at 11:17 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Without = surprise, +1 to differentiate between the back-channel and the = front-channel.

On Thu, Aug 13, 2020 at 5:15 PM Justin = Richer <jricher@mit.edu> wrote:
Denis, I want = to focus on one point here:

In OAuth 2.0, the = user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the = user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the = RS.

One = of my goals with XYZ=E2=80=99s design was to be able to separate the = interaction with the user from the web-based flows for the delegation = protocol, and that aspect is enshrined in the GNAP charter as = well.

It = points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner. 

We already saw bits of this in OAuth 2: = the AS is defined by the pair of the token endpoint and authorization = endpoint, each filling the respective roles above. What if we formally = separate these? Strawman names:


Delegation Server (DS) - handles the back-channel = stuff

Interaction Server (IS) - handles the front-channel = stuff


 =E2=80=94 Justin

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


= --Apple-Mail=_0F40587A-66B2-4AB0-8427-5B79337819E7-- From nobody Thu Aug 13 08:59:48 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 486E43A0E0B for ; Thu, 13 Aug 2020 08:59:46 -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 B0LofLxd1Jgg for ; Thu, 13 Aug 2020 08:59:44 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 2D53C3A0E03 for ; Thu, 13 Aug 2020 08:59:44 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id 185so6751731ljj.7 for ; Thu, 13 Aug 2020 08:59:44 -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=MHv1fwdh01eWYBkIju9ghgAtKtGs407Vr/O+fFTqzS0=; b=TqzjC6aMeAIK/s38au54Dj5J+SJFcVElmBkLeIjosx/Q45T/QnvA3rDb3OlaHtD7j8 74YBYOHNVHZbvQ7tFWec9RfCFsZ3fGM7KDRDOe9vfE477WR6uoIwqM10MBJnm8jjUVq/ C8VHsppNjPbdsqpt/IFMybrXEkOUDiQwmd+1ELHV0xDHuXHWOz2KUypgx0whTjn1sdBP Bvcm5mWbDKlUC4g8oZcYAV5iB6ztFRMbvwrfDrVoo5dqu4uHkhnjZTWFshog7lDKWu6b mshztdZbgNoSRWdChe2G8vzjCEzqDwZnsU9zAPhW9WcuouAiY28t0bqJOeCMAwrE9u2O vp0g== 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=MHv1fwdh01eWYBkIju9ghgAtKtGs407Vr/O+fFTqzS0=; b=SPmaGPcaEeifaHMGqwVgrx2sYwddMw+t6swsFATDnd5TmI6PfbYX4+O1qPoEveyr85 6t+0d9YZ6gzLzWGz2hCk5+EzJ0eGxyLFpJybGAbhY3vuzMRmYLnkrN18m4dfGorhq21n KEr1kpbCY/glTwnQvLiiuUsdztsQPZboY65SKryNB2/mB4hdmlxGoviqKJNNNCjJqRx5 vytGq+lQtYqlK9gbWXkOOJaql9ajcRVtxVjGZYn1KrTvOoY5KDT3Xphq5lz62T1xij0E i7+aZUGQ99sr4pUwcHseEbaGCu79W2LbvE5sp6VKqMVp4YUpbUIaa8Be4LT/4I5e+nvh Z/cQ== X-Gm-Message-State: AOAM5333HSqzuQA6uubgcdA5+vCBos0moWmKzWt+AwZApjWwv1bwgT9+ uZF3WWcgNkw3KnXVXMzq6bLcBvSaVf3jFU0AS6c= X-Google-Smtp-Source: ABdhPJxGEQXlFDuqwncSG8n7DUmG0X5pxiaZY3TtwM34EOy5GG33GbPRAA/a17wbD4jNjGshN8ayAhNII9WL7e9CGc4= X-Received: by 2002:a2e:2283:: with SMTP id i125mr2370711lji.142.1597334382007; Thu, 13 Aug 2020 08:59:42 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <08DEE9CF-F828-4221-AD51-B10AA1B2E9F2@mit.edu> In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 08:59:05 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , "txauth@ietf.org" , Francis Pouatcha , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000006d5b9e05acc4649a" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 15:59:46 -0000 --0000000000006d5b9e05acc4649a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A browser redirect has not been the only way that OAuth has worked. I presented about device flows at IETF when I presented OAuth WRAP. I do think the terms back channel and front channel are unlikely to be helpful in the GNAP work. My point was user awareness rather than protocol. For example, a site making back channel calls to verify a user from a "source" vs a front channel where the user is involved in consenting to the release of data from a "source". =E1=90=A7 On Thu, Aug 13, 2020 at 8:52 AM Justin Richer wrote: > That=E2=80=99s true when the front channel (redirects between parties) is= used as > the method for interaction, but the point I was making is that that metho= d > isn=E2=80=99t going to be the only way that interaction happens. I don=E2= =80=99t think it=E2=80=99s > helpful to conflate other interaction mechanisms that don=E2=80=99t use > redirections with URIs and query parameters as =E2=80=9Cfront channel=E2= =80=9D here. The > security models and surrounding assumptions are very different. > > =E2=80=94 Justin > > On Aug 13, 2020, at 11:40 AM, Dick Hardt wrote: > > I've often thought of front channel as an interaction visible to the user= , > and back channel as being between two software systems, in this case, the > client and GS. > > Consent from the user is the front channel, independent of how the user > gets to the GS, or if an app is part of the GS, or is the GS. > =E1=90=A7 > > On Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault > wrote: > >> Indeed. >> >> On Thu, Aug 13, 2020 at 5:33 PM Justin Richer wrote: >> >>> A point I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D isn= =E2=80=99t going to exist >>> for a lot of systems anymore, where interaction happens through an app = or >>> communication happens through some separate communication fabric. So th= ere >>> are cases, just like in OAuth 2, where there=E2=80=99s only a =E2=80=9C= back channel=E2=80=9D and >>> the other aspect of the AS never comes into play. >>> >>> =E2=80=94 Justin >>> >>> On Aug 13, 2020, at 11:17 AM, Fabien Imbault >>> wrote: >>> >>> Without surprise, +1 to differentiate between the back-channel and the >>> front-channel. >>> >>> On Thu, Aug 13, 2020 at 5:15 PM Justin Richer wrote: >>> >>>> Denis, I want to focus on one point here: >>>> >>>> In OAuth 2.0, the user consent is performed by the AS using an >>>> authorize endpoint where the user consent is solicited and captured. >>>> >>>> Since a user, with no prior experience, shall first connect to a RS to >>>> perform an operation, the user consent shall be performed by the RS, >>>> instead of the AS. This means that we should define a "consent" >>>> endpoint at the RS. >>>> >>>> >>>> One of my goals with XYZ=E2=80=99s design was to be able to separate t= he >>>> interaction with the user from the web-based flows for the delegation >>>> protocol, and that aspect is enshrined in the GNAP charter as well. >>>> >>>> It points to the reality that there are two different aspects of the >>>> traditional AS that we might need to talk about separately now. One de= als >>>> with delegation, issuing tokens, returning data directly to the client= (not >>>> through a separate API, since that=E2=80=99s the RS), and other back-c= hannel stuff. >>>> The other aspect deals with interacting with the user and/or resource >>>> owner. >>>> >>>> We already saw bits of this in OAuth 2: the AS is defined by the pair >>>> of the token endpoint and authorization endpoint, each filling the >>>> respective roles above. What if we formally separate these? Strawman n= ames: >>>> >>>> >>>> Delegation Server (DS) - handles the back-channel stuff >>>> >>>> Interaction Server (IS) - handles the front-channel stuff >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> > --0000000000006d5b9e05acc4649a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A browser redirect has not been the only way that OAuth ha= s worked. I presented about device flows at IETF when I presented OAuth WRA= P.

I do think the terms back channel and front channel a= re unlikely to be helpful in the GNAP work.

My poi= nt was user awareness rather than protocol.

For ex= ample, a site making back channel calls to verify=C2=A0a user from a "= source" vs a front channel where the user is involved in consenting to= the release of data from a "source".

3D""=E1=90=A7

On Thu, Aug 13, 2020 at 8:52 AM Jus= tin Richer <jricher@mit.edu> w= rote:
That=E2=80=99s true when the front channel = (redirects between parties) is used as the method for interaction, but the = point I was making is that that method isn=E2=80=99t going to be the only w= ay that interaction happens. I don=E2=80=99t think it=E2=80=99s helpful to = conflate other interaction mechanisms that don=E2=80=99t use redirections w= ith URIs and query parameters as =E2=80=9Cfront channel=E2=80=9D here. The = security models and surrounding assumptions are very different.=C2=A0
<= br>
=C2=A0=E2=80=94 Justin

=
On Aug 13, 2020, at 11:40 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
<= br>
I've often thought of front channel as an inte= raction visible to the user, and back channel as being between two software= systems, in this case, the client and GS.

Consent from = the user is the front channel, independent of how the user gets to the GS, = or if an app is part of the GS, or is the GS.
3D""=E1= =90=A7

On Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
=
Indeed.

On Thu, Aug 13, 2020 at 5:33 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:
A p= oint I forgot to make below: the =E2=80=9Cfront channel=E2=80=9D isn=E2=80= =99t going to exist for a lot of systems anymore, where interaction happens= through an app or communication happens through some separate communicatio= n fabric. So there are cases, just like in OAuth 2, where there=E2=80=99s o= nly a =E2=80=9Cback channel=E2=80=9D and the other aspect of the AS never c= omes into play.

=C2=A0=E2=80=94 Justin

On Aug 13, 2020, at 11:17 AM, Fabien Imbault <= fabien.imbaul= t@gmail.com> wrote:

Without surprise,= =C2=A0+1 to differentiate=C2=A0between the back-channel and the front-chann= el.

On Thu, Aug 13, 2020 at 5:15 PM Justin Richer <jricher@mit.edu> wrote:
Denis, I want to focus o= n one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.<= /font>

One of my goals with XYZ=E2= =80=99s design was to be able to separate the interaction with the user fro= m the web-based flows for the delegation protocol, and that aspect is enshr= ined in the GNAP charter as well.

It points to the= reality that there are two different aspects of the traditional AS that we= might need to talk about separately now. One deals with delegation, issuin= g tokens, returning data directly to the client (not through a separate API= , since that=E2=80=99s the RS), and other back-channel stuff. The other asp= ect deals with interacting with the user and/or resource owner.=C2=A0
=

We already saw bits of this in OAuth 2: the AS is defin= ed by the pair of the token endpoint and authorization endpoint, each filli= ng the respective roles above. What if we formally separate these? Strawman= names:


Delegation Server (DS) - ha= ndles the back-channel stuff

Interaction Server (I= S) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin

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


--0000000000006d5b9e05acc4649a-- From nobody Thu Aug 13 09:25:17 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 6A3C33A0B31 for ; Thu, 13 Aug 2020 09:25:16 -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 XDmwp3_fkxQk for ; Thu, 13 Aug 2020 09:25:13 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 6E3263A0E57 for ; Thu, 13 Aug 2020 09:25:13 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id v21so5239299otj.9 for ; Thu, 13 Aug 2020 09:25:13 -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=VNF72MRUBBCz5ywb1zVgnKHJvxvZlvVslWrAQw98N4I=; b=vTA1yKGC/uSILQvY5QHLzQYpSLrX0/sdNZIaHHoP39Wa9krtrNu2gc1aC/PhW1g+/q G+UGVmJgMnj4d/5mCH810mCWMwkCT/qnXQcvvhjSnTnjav92rGfh5FVc8wof77tu5fz0 htDnbvhu9j+9oEN6bIyKV4vBnbjBmjbwKwnFOcUfe1wqLRXDsvB2xgMB5f5mPYUW0O73 hFGz7Vc48u8PGGrTGQU/X8sqHVl5uBIvvLXYvAZIxy4n1P/c0UXGb03wrdbeg1moqQbI VIcBSIfxUm9h+xWdyfpp/CMcjvixJmZm44T/d5K63mFXqAKsNPEzWbVzZSoLNnD7U9Od rNaQ== 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=VNF72MRUBBCz5ywb1zVgnKHJvxvZlvVslWrAQw98N4I=; b=TAjoerXMh8RT0vz0feBX+9B+9O4v+SDDLQVd+tFCSV/q2W6A/UbeEMAhXAUN7R9fnd O0DT2s/pNyCSBB6kLjtbaCfcXSX1hbomkymCO3L1W/LgzRSicSFVgkesaA2ZBXH4DWhk qeZNrU5A/x9Qs9dh3+WDkAdzZbdasqFaAqdlTZctY1mH22L0aQHkUDE4NTF5VXGAbS+7 jt7vXrV3kjsTVWB9t2Oxbch3mb3nx47EbL7iTbeBTyRm4f5DU5gjKJ4oEPaIfCxSc48x TTcW+/LcRMiYKX6zdMNaji9zIM1cgdE0Z5GsUjCQCDnpiXYr1eC9Og92F5cATn8H0lyC LnmQ== X-Gm-Message-State: AOAM532AZtBlWE3NnsQXmL9Sp5CCbci7kSB/wZsBUC6s6x1vFFR/jVIj YeosHNkEMR37d7NEMYp8IoDxQUkgezQk6hOM6n8= X-Google-Smtp-Source: ABdhPJx1/NZmjA+625vAtIca1UXbjLjURj14aBeeZcSOen3ahBocVdfzW800bEOFRQgRfxdoJvHeAVBW+2lYi6Zffw4= X-Received: by 2002:a9d:3e49:: with SMTP id h9mr4808527otg.87.1597335912608; Thu, 13 Aug 2020 09:25:12 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 13 Aug 2020 09:25:00 -0700 Message-ID: To: Dick Hardt Cc: Justin Richer , Francis Pouatcha , Denis , Benjamin James Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a87a1305acc4bf8f" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 16:25:16 -0000 --000000000000a87a1305acc4bf8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you want to refer to the role i believe the correct term is user agent. Peace ..tom On Thu, Aug 13, 2020 at 8:27 AM Dick Hardt wrote: > I think Tom's objection, and I agree with it, is that humans don't > interact in bits and bytes. > > I think it is useful to separate human interactions with software from > software interactions with software. The latter we can standardize, the > former we can call out as part of the overall process, but it is not > something that is testable or required for interop, so I would argue huma= n > to software interactions are NOT part of the protocol. > > =E1=90=A7 > > On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: > >> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure where= the objection >> you=E2=80=99re raising comes from. >> >> Also, whatever roles we define here, whether software or human-ware, the= y >> need to be related to the protocol. >> >> =E2=80=94 Justin >> >> On Aug 13, 2020, at 10:59 AM, Tom Jones >> wrote: >> >> I strong object to the objectification of human users. It is way past >> time that the IETF becaume user oriented instead of web service oriented= . >> users are human in my language. >> Peace ..tom >> >> >> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >> >>> If defined as the party operating the client software, then the user is >>> a role. I believe this is more accurate and inclusive than the definiti= on >>> you have proposed with the user as an entity. >>> >>> - Justin >>> ________________________________________ >>> From: Dick Hardt [dick.hardt@gmail.com] >>> Sent: Tuesday, August 11, 2020 6:21 PM >>> To: Francis Pouatcha >>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>> driving use case for the creation of OAuth) >>> >>> Hi Francis >>> >>> The user is an entity, not a role in the protocol in how I am defining >>> roles, so steps (1) and (7) are confusing to me on what is happening. >>> >>> I also think that (2) could be an extension to GNAP, rather than part o= f >>> the core protocol. >>> >>> >>> >>> >>> >>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >> fpo@adorsys.de>> wrote: >>> In this context, I suggest we pick some words to work with, and sharpen >>> them as we move on, discover and map new use cases to the protocol. >>> >>> In this diagram from the original thread ( >>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGN= w/), >>> I replaced the words: >>> >>> +-----------+ +--------------+ +----+ +----+ >>> +---------------------+ >>> | Requestor | | Orchestrator | | | | GS | | Resource >>> Controller | >>> | was | | was | | RS | | or | | was >>> | >>> | User | | Client | | | | AS | | Resource >>> Owner | >>> +-----------+ +--------------+ +----+ +----+ >>> +---------------------+ >>> |(1) ServiceRequest | | | | >>> |---------------------->| | | | >>> | |(2) ServiceIntent:AuthZChallenge | >>> | |<---------->| | | >>> | | | | | >>> | |(3) AuthZRequest(AuthZChallenge) | >>> | |------------------->| | >>> | | | |(4) ConsentRequest:Gran= t >>> | | | |<-------------->| >>> | |(5) GrantAccess(AuthZ) | >>> | |<-------------------| | >>> | | | | | >>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>> | |<---------->| | | >>> |(7) ServiceResponse | | | | >>> |<----------------------| | | | >>> + + + + + >>> >>> The purpose of the GNAP protocol is to help negotiate access to a >>> protected resource. It starts with a requestor delegating activity to a= n >>> orchestrator. These are all roles, no entities. Let focus on mapping th= e >>> use cases to the protocol roles and interactions so wwe can discover wh= at >>> is missing. >>> >>> It seems cumbersome to use it in discussions as it is impossible to giv= e >>> the word "Client" a clear definition. >>> >>> We can mention in the final document, that the "Orchestrator" (or >>> whatever word we finally use) plays the same role as the "Client" in oA= uth2. >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> >>> >>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >> dick.hardt@gmail.com>> wrote: >>> I agree with Justin. Redefining well used terms will lead to significan= t >>> confusion. If we have a different role than what we have had in the pas= t, >>> then that role should have a name not being used already in OAuth or OI= DC. >>> >>> Given what we have learned, and my own experience explaining what a >>> Client is, and is not, improving the definition for Client could prove >>> useful. I am not suggesting the term be redefined, but clarified. >>> >>> For example, clarifying that a Client is a role an entity plays in the >>> protocol, and that the same entity may play other roles at other times,= or >>> some other language to help differentiate between "role" and "entity". >>> >>> /Dick >>> [ >>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7 >>> >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >> jricher@mit.edu>> wrote: >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m >>> not really in favor of taking an existing term and applying a completel= y >>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>> and come up with a new, more specific and accurate term for the role th= an >>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diff= erent. We did this >>> in going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >>> >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is >>> ignore the fact that GNAP is going to be coming up in a world that is >>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t hav= e a blank >>> slate to work with, but neither are we bound to use the same terms and >>> constructs as before. It=E2=80=99s going to be a delicate balance! >>> >>> =E2=80=94 Justin >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad >> wparad@rhosys.ch>> wrote: >>> >>> I think that is fundamentally part of the question: >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion >>> >>> If we say that this document assumes OAuth2.0 terminology, then we >>> should not change the meanings of any definition. If we are saying this >>> supersedes or replaces what OAuth 2.0 creates, then we should pick the = best >>> word for the job and ignore conflicting meanings from OAuth 2.0. I have= a >>> lot of first hand experience of industries "ruining words", and attempt= ing >>> to side-step the problem rather than redefining the word just confuses >>> everyone as everyone forgets the original meaning as new documents come >>> out, but the confusion with the use of a non-obvious word continues. >>> >>> Food for thought. >>> - Warren >>> >>> [ >>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZO= sW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hju= Im9GCeBRRzrSc8kWcUSNtuA >>> ] >>> >>> Warren Parad >>> Founder, CTO >>> >>> Secure your user data and complete your authorization architecture. >>> Implement Authress. >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >> kaduk@mit.edu>> wrote: >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response similar to the >>> one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in use= here. >>> What >>> > > you describe as RS2, which might in fact be an RS unto itself, is a >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world,= but it is not at >>> > > all the same as an OAuth client. I appreciate your mapping of the >>> > > entities below, but it makes it difficult to hold a discussion if w= e >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can define >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>> definitions, >>> > > but we=E2=80=99ve got a chance to be more precise with how we defin= e things. >>> > >>> > In the ISO context, each document must define its own terminology. Th= e >>> > boiler plate for RFCs does not mandate a terminology or definitions >>> section >>> > but does not prevent it either. The vocabulary is limited and as long >>> as >>> > we clearly define what our terms are meaning, we can re-use a term >>> already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily mean that it is a >>> good idea to do so. We are clear that we are producing a protocol that >>> is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted Dic= k >>> to >>> use the term "GS" in XAuth, picking a name that was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> 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/ >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> --000000000000a87a1305acc4bf8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you want to refer to the role i believe the correct ter= m is user agent.
Peace = ..tom


On Thu, Aug 13, 2020 at 8:27 AM Dick= Hardt <dick.hardt@gmail.com= > wrote:
I think Tom's objection, and I agree with it, is that huma= ns don't interact in bits and bytes.=C2=A0

I think i= t is useful to separate human interactions with software from software inte= ractions with software. The latter we can standardize, the former we can ca= ll out as part of the overall process, but it is not something that is test= able or required for interop, so I would argue human to software interactio= ns are NOT part of the protocol.

3D""=E1=90=A7

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote= :
It=E2=80= =99s a role fulfilled by a person, so I=E2=80=99m not sure where the object= ion you=E2=80=99re raising comes from.

Also, whatever ro= les we define here, whether software or human-ware, they need to be related= to the protocol.

=C2=A0=E2=80=94 Justin

On Aug 13, 2020, at 10:59 AM, Tom Jone= s <tho= masclinganjones@gmail.com> wrote:

I s= trong object to the objectification of human users. It is way past time tha= t the IETF becaume user oriented instead of web service oriented.
users= are human in my language.
Peace ..tom


On Tue, Aug 11, = 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client sof= tware, then the user is a role. I believe this is more accurate and inclusi= ve than the definition you have proposed with the user as an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a drivin= g use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining role= s, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of th= e core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen the= m as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOB= JqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+=C2=A0 +----+=C2=A0 +----= +=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrator |=C2=A0 |=C2=A0 =C2=A0 |= =C2=A0 | GS |=C2=A0 | Resource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client= =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |=C2=A0 =C2= =A0 Resource Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+=C2=A0 +----+=C2=A0 +----= +=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =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) ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 = =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected= resource. It starts with a requestor delegating activity to an orchestrato= r. These are all roles, no entities. Let focus on mapping the use cases to = the protocol roles and interactions so wwe can discover what is missing.
It seems cumbersome to use it in discussions as it is impossible to give th= e word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or= whatever word we finally use) plays the same role as the "Client"= ; in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
I agree with Justin. Redefining well used terms will lead to significant co= nfusion. If we have a different role than what we have had in the past, the= n that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client = is, and is not, improving the definition for Client could prove useful. I a= m not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the prot= ocol, and that the same entity may play other roles at other times, or some= other language to help differentiate between "role" and "en= tity".

/Dick
[https://mailfoogae.a= ppspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=3Dzeroconten= t&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto= :jricher@mit.edu&g= t;> wrote:
I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better f= it, but I=E2=80=99m not really in favor of taking an existing term and appl= ying a completely new definition to it. In other words, I would sooner stop= using =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and a= ccurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meanin= g something completely different. We did this in going from OAuth 1 to OAut= h 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D= to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2= =80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2=80=9D on= its own but instead always qualifies it with =E2=80=9CAuthorization Server= =E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do = is ignore the fact that GNAP is going to be coming up in a world that is al= ready permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have= a blank slate to work with, but neither are we bound to use the same terms= and constructs as before. It=E2=80=99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should n= ot change the meanings of any definition. If we are saying this supersedes = or replaces what OAuth 2.0 creates, then we should pick the best word for t= he job and ignore conflicting meanings from OAuth 2.0. I have a lot of firs= t hand experience of industries "ruining words", and attempting t= o side-step the problem rather than redefining the word just confuses every= one as everyone forgets the original meaning as new documents come out, but= the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https= ://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A7= 4mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRR= zrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Impleme= nt Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the o= ne
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a problem with the terminology in u= se here. What
> > you describe as RS2, which might in fact be an RS unto itself, is= a
> > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the=
> > entities below, but it makes it difficult to hold a discussion if= we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
> > our own terms. The bad news is that this is really hard to do. > >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
> > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
>
> In the ISO context, each document must define its own terminology. The=
> boiler plate for RFCs does not mandate a terminology or definitions se= ction
> but does not prevent it either. The vocabulary is limited and as long = as
> we clearly define what our terms are meaning, we can re-use a term alr= eady
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
use the term "GS" in XAuth, picking a name that was not already u= sed in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<= ;mailto:Txauth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<= ;mailto:Txauth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<= ;mailto:TXAuth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<= ;mailto:TXAuth@ietf.or= g>
https://www.ietf.org/mailman/listinfo/txauth


--
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

--000000000000a87a1305acc4bf8f-- From nobody Thu Aug 13 10:28:12 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 A41CD3A0FAC for ; Thu, 13 Aug 2020 10:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PHoRZWtUwbZr for ; Thu, 13 Aug 2020 10:28:01 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A266A3A0F95 for ; Thu, 13 Aug 2020 10:28:00 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d82 with ME id F5Tx2300P2bcEcA035TyVk; Thu, 13 Aug 2020 19:27:58 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 19:27:58 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> From: Denis Message-ID: Date: Thu, 13 Aug 2020 19:27:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9D454F87EF0CB5F03FF85440" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 17:28:11 -0000 This is a multi-part message in MIME format. --------------9D454F87EF0CB5F03FF85440 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dick, > I think Tom's objection, and I agree with it, is that humans don't > interact in bits and bytes. > > I think it is useful to separate human interactions with software from > software interactions with software. > The latter we can standardize, the former we can call out as part of > the overall process, but it is not something > that is testable or required for interop, so I would argue human to > software interactions are NOT part of the protocol. I disagree.  A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know the end result of these choices when/if it gets back one or more access tokens. Human to software interactions should be part of the protocol. RS to Client: a set of choices Client to RS: Done (choices have been done by the user). Denis > > ᐧ > > On Thu, Aug 13, 2020 at 8:11 AM Justin Richer > wrote: > > It’s a role fulfilled by a person, so I’m not sure where the > objection you’re raising comes from. > > Also, whatever roles we define here, whether software or > human-ware, they need to be related to the protocol. > >  — Justin > >> On Aug 13, 2020, at 10:59 AM, Tom Jones >> > > wrote: >> >> I strong object to the objectification of human users. It is way >> past time that the IETF becaume user oriented instead of web >> service oriented. >> users are human in my language. >> Peace ..tom >> >> >> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer > > wrote: >> >> If defined as the party operating the client software, then >> the user is a role. I believe this is more accurate and >> inclusive than the definition you have proposed with the user >> as an entity. >> >>  - Justin >> ________________________________________ >> From: Dick Hardt [dick.hardt@gmail.com >> ] >> Sent: Tuesday, August 11, 2020 6:21 PM >> To: Francis Pouatcha >> Cc: Justin Richer; Denis; Benjamin James Kaduk; >> txauth@ietf.org >> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing >> example (a driving use case for the creation of OAuth) >> >> Hi Francis >> >> The user is an entity, not a role in the protocol in how I am >> defining roles, so steps (1) and (7) are confusing to me on >> what is happening. >> >> I also think that (2) could be an extension to GNAP, rather >> than part of the core protocol. >> >> >> >> >> >> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >> > >> wrote: >> In this context, I suggest we pick some words to work with, >> and sharpen them as we move on, discover and map new use >> cases to the protocol. >> >> In this diagram from the original thread >> (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), >> I replaced the words: >> >> +-----------+      +--------------+  +----+ +----+  >> +---------------------+ >> | Requestor |      | Orchestrator |  |    | | GS |  | >> Resource Controller | >> |   was     |      |     was      |  | RS | | or |  |        >>  was         | >> |  User     |      |   Client     |  |    | | AS |  |    >> Resource Owner   | >> +-----------+      +--------------+  +----+ +----+  >> +---------------------+ >>   |(1) ServiceRequest     |            |    |                | >>   |---------------------->|            |      |                | >>   |                       |(2) ServiceIntent:AuthZChallenge     | >>   |  |<---------->|       | | >>   |                       |            |    |                | >>   |                       |(3) AuthZRequest(AuthZChallenge)     | >>   |  |------------------->|                | >>   |                       |            |    |(4) >> ConsentRequest:Grant >>   |                       |            |    |<-------------->| >>   |                       |(5) GrantAccess(AuthZ)               | >>   |  |<-------------------|                | >>   |                       |            |    |                | >>   |                       |(6) >> ServiceRequest(AuthZ):ServiceResponse >>   |  |<---------->|       | | >>   |(7) ServiceResponse    |            |    |                | >>   |<----------------------|            |      |                | >>   +                       +            +    +                + >> >> The purpose of the GNAP protocol is to help negotiate access >> to a protected resource. It starts with a requestor >> delegating activity to an orchestrator. These are all roles, >> no entities. Let focus on mapping the use cases to the >> protocol roles and interactions so wwe can discover what is >> missing. >> >> It seems cumbersome to use it in discussions as it is >> impossible to give the word "Client" a clear definition. >> >> We can mention in the final document, that the "Orchestrator" >> (or whatever word we finally use) plays the same role as the >> "Client" in oAuth2. >> >> Best regards. >> /Francis >> >> >> >> >> >> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >> > > >> wrote: >> I agree with Justin. Redefining well used terms will lead to >> significant confusion. If we have a different role than what >> we have had in the past, then that role should have a name >> not being used already in OAuth or OIDC. >> >> Given what we have learned, and my own experience explaining >> what a Client is, and is not, improving the definition for >> Client could prove useful. I am not suggesting the term be >> redefined, but clarified. >> >> For example, clarifying that a Client is a role an entity >> plays in the protocol, and that the same entity may play >> other roles at other times, or some other language to help >> differentiate between "role" and "entity". >> >> /Dick >> [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ >> >> >> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >> > >> wrote: >> I’m in favor of coming up with a new term that’s a better >> fit, but I’m not really in favor of taking an existing term >> and applying a completely new definition to it. In other >> words, I would sooner stop using “client” and come up with a >> new, more specific and accurate term for the role than to >> define “client” as meaning something completely different. We >> did this in going from OAuth 1 to OAuth 2 already, moving >> from the even-more-confusing “consumer” to “client”, but >> OAuth 2 doesn’t use the term “consumer” at all, nor does it >> use “server” on its own but instead always qualifies it with >> “Authorization Server” and “Resource Server”. >> >> GNAP can do something similar, in my opinion. But what we >> can’t do is ignore the fact that GNAP is going to be coming >> up in a world that is already permeated  by OAuth 2 and its >> terminology. We don’t have a blank slate to work with, but >> neither are we bound to use the same terms and constructs as >> before. It’s going to be a delicate balance! >> >>  — Justin >> >> On Aug 4, 2020, at 3:32 PM, Warren Parad > > >> wrote: >> >> I think that is fundamentally part of the question: >> We are clear that we are producing a protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and >> reusing terms >> from OAuth 2.0 but with different definitions may lead to >> unnecessary >> confusion >> >> If we say that this document assumes OAuth2.0 terminology, >> then we should not change the meanings of any definition. If >> we are saying this supersedes or replaces what OAuth 2.0 >> creates, then we should pick the best word for the job and >> ignore conflicting meanings from OAuth 2.0. I have a lot of >> first hand experience of industries "ruining words", and >> attempting to side-step the problem rather than redefining >> the word just confuses everyone as everyone forgets the >> original meaning as new documents come out, but the confusion >> with the use of a non-obvious word continues. >> >> Food for thought. >> - Warren >> >> [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA] >> >> Warren Parad >> Founder, CTO >> >> Secure your user data and complete your authorization >> architecture. Implement Authress> .ly/37SSO1p>. >> >> >> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk > > >> wrote: >> Hi Denis, >> >> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >> > Hi Justin, >> > >> > Since you replied in parallel, I will make a response >> similar to the one >> > I sent to Dick. >> > >> > > Hi Denis, >> > > >> > > I think there’s still a problem with the terminology in >> use here. What >> > > you describe as RS2, which might in fact be an RS unto >> itself, is a >> > > “Client” in OAuth parlance because it is /a client of >> RS1/. What you >> > > call a “client” has no analogue in the OAuth world, but >> it is not at >> > > all the same as an OAuth client. I appreciate your >> mapping of the >> > > entities below, but it makes it difficult to hold a >> discussion if we >> > > aren’t using the same terms. >> > > >> > > The good news is that this isn’t OAuth, and as a new WG >> we can define >> > > our own terms. The bad news is that this is really hard >> to do. >> > > >> > > In GNAP, we shouldn’t just re-use existing terms with new >> definitions, >> > > but we’ve got a chance to be more precise with how we >> define things. >> > >> > In the ISO context, each document must define its own >> terminology. The >> > boiler plate for RFCs does not mandate a terminology or >> definitions section >> > but does not prevent it either. The vocabulary is limited >> and as long as >> > we clearly define what our terms are meaning, we can re-use >> a term already >> > used in another RFC. This is also the ISO approach. >> >> Just because we can do something does not necessarily mean >> that it is a >> good idea to do so.  We are clear that we are producing a >> protocol that is >> conceptually (if not more strongly) related to OAuth 2.0, and >> reusing terms >> from OAuth 2.0 but with different definitions may lead to >> unnecessary >> confusion.  If I understand correctly, a similar reasoning >> prompted Dick to >> use the term "GS" in XAuth, picking a name that was not >> already used in >> OAuth 2.0. >> >> -Ben >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> > > >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> Txauth mailing list >> Txauth@ietf.org >> > > >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> > > >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> 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/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --------------9D454F87EF0CB5F03FF85440 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dick,

I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes. 

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.  A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



ᐧ

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It’s a role fulfilled by a person, so I’m not sure where the objection you’re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

 — Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

 - Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto: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/
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--------------9D454F87EF0CB5F03FF85440-- From nobody Thu Aug 13 10:29:39 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 15B203A0F3B for ; Thu, 13 Aug 2020 10:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 b8EB2CfEZTNc for ; Thu, 13 Aug 2020 10:29:32 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066943A0F65 for ; Thu, 13 Aug 2020 10:29:27 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d82 with ME id F5VN230042bcEcA035VNaQ; Thu, 13 Aug 2020 19:29:26 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 19:29:26 +0200 X-ME-IP: 90.79.51.120 To: Justin Richer Cc: "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> From: Denis Message-ID: <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> Date: Thu, 13 Aug 2020 19:29:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------13D9BBCA3BE02CC9FE878406" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 17:29:38 -0000 This is a multi-part message in MIME format. --------------13D9BBCA3BE02CC9FE878406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit  Justin, Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS. Denis > Denis, I want to focus on one point here: > >> In OAuth 2.0, the user consent is performed by the AS using an >> authorize endpoint where the user consent is solicited and captured. >> >> Since a user, with no prior experience, shall first connect to a RS >> to perform an operation, the user consent shall be performed by the RS, >> instead of the AS. This means that we should define a "consent" >> endpoint at the RS. > > One of my goals with XYZ’s design was to be able to separate the > interaction with the user from the web-based flows for the delegation > protocol, and that aspect is enshrined in the GNAP charter as well. > > It points to the reality that there are two different aspects of the > traditional AS that we might need to talk about separately now. One > deals with delegation, issuing tokens, returning data directly to the > client (not through a separate API, since that’s the RS), and other > back-channel stuff. The other aspect deals with interacting with the > user and/or resource owner. > > We already saw bits of this in OAuth 2: the AS is defined by the pair > of the token endpoint and authorization endpoint, each filling the > respective roles above. What if we formally separate these? Strawman > names: > > Delegation Server (DS) - handles the back-channel stuff > > Interaction Server (IS) - handles the front-channel stuff > > >  — Justin > --------------13D9BBCA3BE02CC9FE878406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
 Justin,

Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

Denis

Denis, I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.

One of my goals with XYZ’s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that’s the RS), and other back-channel stuff. The other aspect deals with interacting with the user and/or resource owner. 

We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

Delegation Server (DS) - handles the back-channel stuff

Interaction Server (IS) - handles the front-channel stuff


 — Justin


--------------13D9BBCA3BE02CC9FE878406-- From nobody Thu Aug 13 10:31:22 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 12B6A3A0F6D for ; Thu, 13 Aug 2020 10:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no autolearn_force=no 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 eXsJ02bHz9XE for ; Thu, 13 Aug 2020 10:31:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F7A3A1009 for ; Thu, 13 Aug 2020 10:31:01 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d82 with ME id F5Wz230062bcEcA035WzgA; Thu, 13 Aug 2020 19:30:59 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 19:30:59 +0200 X-ME-IP: 90.79.51.120 To: "txauth@ietf.org" From: Denis Message-ID: Date: Thu, 13 Aug 2020 19:30:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B30B4802B6F5F49FA66EE5AA" Content-Language: en-GB Archived-At: Subject: [GNAP] Support of FIDO 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: Thu, 13 Aug 2020 17:31:21 -0000 This is a multi-part message in MIME format. --------------B30B4802B6F5F49FA66EE5AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This topic has already been tackled on the list, but I open a new thread for it. In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens, there have been used everywhere, even when they were not strictly needed. It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user and no trust relationships need to be defined since there is no AS. FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim. RFC 7519 states: The "sub" (subject) claim identifies the principal that is the subject of the JWT.The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer) while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server (i.e. not supporting OAuth) that is using the same globally unique identifier. None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS. Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible. There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth. Denis --------------B30B4802B6F5F49FA66EE5AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
and no trust relationships need to be defined since there is no AS.

FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.

RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.

None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible. 

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis

--------------B30B4802B6F5F49FA66EE5AA-- From nobody Thu Aug 13 11:01:19 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 1A0703A0FF4 for ; Thu, 13 Aug 2020 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YA5xnusWmD7q for ; Thu, 13 Aug 2020 11:01:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665653A0FDF for ; Thu, 13 Aug 2020 11:01:14 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07DI1BGw026286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Aug 2020 14:01:11 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D8818BF3-ACBB-49E5-803B-059A546E2146" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 13 Aug 2020 14:01:11 -0400 In-Reply-To: <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> Cc: "txauth@ietf.org" To: Denis References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 18:01:18 -0000 --Apple-Mail=_D8818BF3-ACBB-49E5-803B-059A546E2146 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So what I=E2=80=99m saying is that what you=E2=80=99re defining as part = of the RS was (in Oauth) defined as a function of the AS. As such, I = contend that it needs to be its own separate functional role, neither AS = nor RS. That way it could be fulfilled by an entity either closely tied to the = AS or closely tied to the RS, as appropriate. It would give us more = flexibility to talk about the patterns. =E2=80=94 Justin > On Aug 13, 2020, at 1:29 PM, Denis wrote: >=20 > Justin, >=20 > Your response does not address my point. I am talking of two different = channels with the RS, i.e. not with the AS. >=20 > Denis >=20 >> Denis, I want to focus on one point here: >>=20 >>> In OAuth 2.0, the user consent is performed by the AS using an = authorize endpoint where the user consent is solicited and captured. >>>=20 >>> Since a user, with no prior experience, shall first connect to a RS = to perform an operation, the user consent shall be performed by the RS,=20= >>> instead of the AS. This means that we should define a "consent" = endpoint at the RS. >>=20 >> One of my goals with XYZ=E2=80=99s design was to be able to separate = the interaction with the user from the web-based flows for the = delegation protocol, and that aspect is enshrined in the GNAP charter as = well. >>=20 >> It points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner.=20 >>=20 >> We already saw bits of this in OAuth 2: the AS is defined by the pair = of the token endpoint and authorization endpoint, each filling the = respective roles above. What if we formally separate these? Strawman = names: >>=20 >> Delegation Server (DS) - handles the back-channel stuff >>=20 >> Interaction Server (IS) - handles the front-channel stuff >>=20 >>=20 >> =E2=80=94 Justin >>=20 >=20 --Apple-Mail=_D8818BF3-ACBB-49E5-803B-059A546E2146 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So = what I=E2=80=99m saying is that what you=E2=80=99re defining as part of = the RS was (in Oauth) defined as a function of the AS. As such, I = contend that it needs to be its own separate functional role, neither AS = nor RS.

That way it = could be fulfilled by an entity either closely tied to the AS or closely = tied to the RS, as appropriate. It would give us more flexibility to = talk about the patterns.

 =E2=80=94 Justin

On Aug 13, 2020, at 1:29 PM, Denis <denis.ietf@free.fr> = wrote:

=20
 Justin,

Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

Denis

=20 Denis, I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, = the user consent shall be performed by the RS,
instead of the AS. = This means that we should define a "consent" endpoint at the RS.

One of my goals with XYZ=E2=80=99s design was to = be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two = different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that=E2=80=99s the RS), and other back-channel = stuff. The other aspect deals with interacting with the user and/or resource owner. 

We already saw bits of this in OAuth 2: the AS = is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

Delegation Server (DS) - handles the = back-channel stuff

Interaction Server (IS) - handles the = front-channel stuff


 =E2=80=94 Justin



= --Apple-Mail=_D8818BF3-ACBB-49E5-803B-059A546E2146-- From nobody Thu Aug 13 11:17:12 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 2BBEB3A0FFA for ; Thu, 13 Aug 2020 11:17:08 -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 hYWAOxHR6pUR for ; Thu, 13 Aug 2020 11:17:05 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B81893A1082 for ; Thu, 13 Aug 2020 11:16:52 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id k13so3543579lfo.0 for ; Thu, 13 Aug 2020 11:16:52 -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=qNiXbXZPZs7Y6G2RwVu0bjm2VzhApsxnEcrCkfbq22M=; b=lOe2UCKcByqL9JJj3QyT5SBRx0AePMY/fEtQFSnCogrFKNdZu7e561o6wqnj63uLGV trYYtSmpe4upoH2OnAyTOV3sdv9tldVDkc9iFZadi1Kjhb0Vun0d8NCExUogXr6e3IJy hq4aKjxK2MUSPqPY11z2gQAuj+ul7goHDhFxWaXg/X948cU1qkltkcC4if6hvPbhwAnG w1s8q9URmjYza4+8/utS3lzLpfmdubH8TBB3WaseXJncRRFF+OWZmVkLGDBNafalaSVq B+n0OkntDuYrLMxSxr1ph+QKyU9JBgf4hAYY8Nx+lCNwhpcq1MZdQ+aU4jC8W77v27Qm UBoQ== 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=qNiXbXZPZs7Y6G2RwVu0bjm2VzhApsxnEcrCkfbq22M=; b=AKMtIC4QQihtPjXGNT7ij8bbISfosakzrNTJpN/bl8T/rmj4IJLN/OB8a5OascQS71 QFTSSnVnCAh3VVzEPhdsjmi64jtxacYvDfVFB20qQ3v8mwBRG2UgvdosbAgwLXN9RqGc e5UflRxJ+DhHrN3FQdmQ0z/Xoq1L8HlpxlZelEZpyDWRhprAstOKLQU7gPHzPmH9m6Xa uM6UuG80C+jLDxBLY4/hJnQdnwRLkBiiVzIH/bX6bxfGJsT+TUDFPiAvP6SDmbcAmHiX U7nazpjb8cytJYbmczUXA8pQ6HHeHT2n0JmAmdT/ilrLx5FOnFni8+MmS3hCC/dMkSYu A+bA== X-Gm-Message-State: AOAM531/Hn9wfeypHEyIExKFn/HGvMxYUCPoqE5oApMxKFxAHNkCHM5O Ch7XdaYubk5BYIk5Oab3skkWnJ/kG2uqWPOd7fM= X-Google-Smtp-Source: ABdhPJxiJKR5X6iTzjjQw5quxnxyNMDUKaqaSzC9JPfHQ9fH2Jk188NB7lm2iYjOzZcRFrAqtoUxtR71HYmX32tMvWI= X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr2779480lfp.23.1597342610648; Thu, 13 Aug 2020 11:16:50 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 11:16:14 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e472a405acc64e90" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 18:17:08 -0000 --000000000000e472a405acc64e90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability. In many jurisdictions there are regulations regarding what information needs to be conveyed to a user, and potentially a consent requirement, for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that. On a related note, the browsers attempted to standardize the username / password prompt, and that has been rejected by pretty much every site. The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating experience since there was no button for account recovery -- it would just keep popping up. =E1=90=A7 On Thu, Aug 13, 2020 at 10:29 AM Denis wrote: > Dick, > > I think Tom's objection, and I agree with it, is that humans don't > interact in bits and bytes. > > I think it is useful to separate human interactions with software from > software interactions with software. > The latter we can standardize, the former we can call out as part of the > overall process, but it is not something > that is testable or required for interop, so I would argue human to > software interactions are NOT part of the protocol. > > I disagree. A set of a choices should be presented by the RS to the > Client in a standardized way. The choices made by the user > should be locally recorded by the Client, hence the RS does not need to b= e > informed of these choices. The RS will only know > the end result of these choices when/if it gets back one or more access > tokens. > > Human to software interactions should be part of the protocol. > > RS to Client: a set of choices > > Client to RS: Done (choices have been done by the user). > > Denis > > > > =E1=90=A7 > > On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: > >> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure where= the objection >> you=E2=80=99re raising comes from. >> >> Also, whatever roles we define here, whether software or human-ware, the= y >> need to be related to the protocol. >> >> =E2=80=94 Justin >> >> On Aug 13, 2020, at 10:59 AM, Tom Jones >> wrote: >> >> I strong object to the objectification of human users. It is way past >> time that the IETF becaume user oriented instead of web service oriented= . >> users are human in my language. >> Peace ..tom >> >> >> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >> >>> If defined as the party operating the client software, then the user is >>> a role. I believe this is more accurate and inclusive than the definiti= on >>> you have proposed with the user as an entity. >>> >>> - Justin >>> ________________________________________ >>> From: Dick Hardt [dick.hardt@gmail.com] >>> Sent: Tuesday, August 11, 2020 6:21 PM >>> To: Francis Pouatcha >>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>> driving use case for the creation of OAuth) >>> >>> Hi Francis >>> >>> The user is an entity, not a role in the protocol in how I am defining >>> roles, so steps (1) and (7) are confusing to me on what is happening. >>> >>> I also think that (2) could be an extension to GNAP, rather than part o= f >>> the core protocol. >>> >>> >>> >>> >>> >>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >> fpo@adorsys.de>> wrote: >>> In this context, I suggest we pick some words to work with, and sharpen >>> them as we move on, discover and map new use cases to the protocol. >>> >>> In this diagram from the original thread ( >>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGN= w/), >>> I replaced the words: >>> >>> +-----------+ +--------------+ +----+ +----+ >>> +---------------------+ >>> | Requestor | | Orchestrator | | | | GS | | Resource >>> Controller | >>> | was | | was | | RS | | or | | was >>> | >>> | User | | Client | | | | AS | | Resource >>> Owner | >>> +-----------+ +--------------+ +----+ +----+ >>> +---------------------+ >>> |(1) ServiceRequest | | | | >>> |---------------------->| | | | >>> | |(2) ServiceIntent:AuthZChallenge | >>> | |<---------->| | | >>> | | | | | >>> | |(3) AuthZRequest(AuthZChallenge) | >>> | |------------------->| | >>> | | | |(4) ConsentRequest:Gran= t >>> | | | |<-------------->| >>> | |(5) GrantAccess(AuthZ) | >>> | |<-------------------| | >>> | | | | | >>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>> | |<---------->| | | >>> |(7) ServiceResponse | | | | >>> |<----------------------| | | | >>> + + + + + >>> >>> The purpose of the GNAP protocol is to help negotiate access to a >>> protected resource. It starts with a requestor delegating activity to a= n >>> orchestrator. These are all roles, no entities. Let focus on mapping th= e >>> use cases to the protocol roles and interactions so wwe can discover wh= at >>> is missing. >>> >>> It seems cumbersome to use it in discussions as it is impossible to giv= e >>> the word "Client" a clear definition. >>> >>> We can mention in the final document, that the "Orchestrator" (or >>> whatever word we finally use) plays the same role as the "Client" in oA= uth2. >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> >>> >>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >> dick.hardt@gmail.com>> wrote: >>> I agree with Justin. Redefining well used terms will lead to significan= t >>> confusion. If we have a different role than what we have had in the pas= t, >>> then that role should have a name not being used already in OAuth or OI= DC. >>> >>> Given what we have learned, and my own experience explaining what a >>> Client is, and is not, improving the definition for Client could prove >>> useful. I am not suggesting the term be redefined, but clarified. >>> >>> For example, clarifying that a Client is a role an entity plays in the >>> protocol, and that the same entity may play other roles at other times,= or >>> some other language to help differentiate between "role" and "entity". >>> >>> /Dick >>> [ >>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90=A7 >>> >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >> jricher@mit.edu>> wrote: >>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bett= er fit, but I=E2=80=99m >>> not really in favor of taking an existing term and applying a completel= y >>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>> and come up with a new, more specific and accurate term for the role th= an >>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely diff= erent. We did this >>> in going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80= =9D, but OAuth 2 doesn=E2=80=99t use the >>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead >>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2= =80=9CResource Server=E2=80=9D. >>> >>> GNAP can do something similar, in my opinion. But what we can=E2=80=99t= do is >>> ignore the fact that GNAP is going to be coming up in a world that is >>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t hav= e a blank >>> slate to work with, but neither are we bound to use the same terms and >>> constructs as before. It=E2=80=99s going to be a delicate balance! >>> >>> =E2=80=94 Justin >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad >> wparad@rhosys.ch>> wrote: >>> >>> I think that is fundamentally part of the question: >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion >>> >>> If we say that this document assumes OAuth2.0 terminology, then we >>> should not change the meanings of any definition. If we are saying this >>> supersedes or replaces what OAuth 2.0 creates, then we should pick the = best >>> word for the job and ignore conflicting meanings from OAuth 2.0. I have= a >>> lot of first hand experience of industries "ruining words", and attempt= ing >>> to side-step the problem rather than redefining the word just confuses >>> everyone as everyone forgets the original meaning as new documents come >>> out, but the confusion with the use of a non-obvious word continues. >>> >>> Food for thought. >>> - Warren >>> >>> [ >>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZO= sW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hju= Im9GCeBRRzrSc8kWcUSNtuA >>> ] >>> >>> Warren Parad >>> Founder, CTO >>> >>> Secure your user data and complete your authorization architecture. >>> Implement Authress. >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >> kaduk@mit.edu>> wrote: >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response similar to the >>> one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there=E2=80=99s still a problem with the terminology in use= here. >>> What >>> > > you describe as RS2, which might in fact be an RS unto itself, is a >>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client = of RS1/. What you >>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world,= but it is not at >>> > > all the same as an OAuth client. I appreciate your mapping of the >>> > > entities below, but it makes it difficult to hold a discussion if w= e >>> > > aren=E2=80=99t using the same terms. >>> > > >>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we = can define >>> > > our own terms. The bad news is that this is really hard to do. >>> > > >>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>> definitions, >>> > > but we=E2=80=99ve got a chance to be more precise with how we defin= e things. >>> > >>> > In the ISO context, each document must define its own terminology. Th= e >>> > boiler plate for RFCs does not mandate a terminology or definitions >>> section >>> > but does not prevent it either. The vocabulary is limited and as long >>> as >>> > we clearly define what our terms are meaning, we can re-use a term >>> already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily mean that it is a >>> good idea to do so. We are clear that we are producing a protocol that >>> is >>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>> terms >>> from OAuth 2.0 but with different definitions may lead to unnecessary >>> confusion. If I understand correctly, a similar reasoning prompted Dic= k >>> to >>> use the term "GS" in XAuth, picking a name that was not already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> 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/ >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000e472a405acc64e90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see how we can technically standardize a user = experience, and it is not clear why a standard would be needed for interope= rability.

=C2=A0In many jurisdictions there are regulati= ons regarding what information needs to be conveyed to a user, and potentia= lly a consent requirement, for example a site explaining its use of cookies= -- but I don't see how IETF would play a role in that.=C2=A0

On a related note, the browsers=C2=A0attempted to standardi= ze the username / password prompt, and that has been rejected by pretty muc= h every site. The only site I've visited in the last decade that has us= ed the browsers' built in username / password prompt was the W3C site -= - and it was a frustrating experience since there was no button for account= recovery -- it would just keep popping up.


=3D""=E1=90=A7

On Thu, Aug 13, 2020 at 10:29 AM Denis = <denis.ietf@free.fr> wrote:=
=20 =20 =20
Dick,

=20
I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes.=C2=A0

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.=C2=A0 A set of a choices should be presented by the RS t= o the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



3D""==E1=90=A7

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure where the objection you=E2= =80=99re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

=C2=A0=E2=80=94 Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclingan= jones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arc= h/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +------------= --+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orchestrato= r |=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | GS |=C2=A0 | Resource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |= =C2=A0 | or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2= =A0 | AS |=C2=A0 |=C2=A0 =C2=A0 Resource Owner=C2= =A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +------------= --+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2= =A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2= =A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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) ConsentRequest: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 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------->|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word = we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and &quo= t;entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5j= b20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac= 3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m no= t really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up with a new= , more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as meaning s= omething completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80= =9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2= =80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it = use =E2=80=9Cserver=E2=80=9D on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and= =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ignore= the fact that GNAP is going to be coming up in a world that is already permeated=C2=A0 by OAuth = 2 and its terminology. We don=E2=80=99t have a bl= ank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2=80=99s going to be a delicate bal= ance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruini= ng words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1= oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r= 9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still a probl= em with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in OAuth par= lance because it is /a client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80=9D has n= o analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms.<= br> > >
> > The good news is that this isn=E2=80= =99t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re= -use existing terms with new definitions,
> > but we=E2=80=99ve got a chance to be = more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a= name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman= /listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman= /listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman= /listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto: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/soluti= ons/
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman= /listinfo/txauth


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000e472a405acc64e90-- From nobody Thu Aug 13 11:21:54 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 3A1693A101C for ; Thu, 13 Aug 2020 11:21:54 -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 hK_pXzoYfyBy for ; Thu, 13 Aug 2020 11:21:52 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 1797A3A102D for ; Thu, 13 Aug 2020 11:21:52 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id z14so7264108ljm.1 for ; Thu, 13 Aug 2020 11:21:51 -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=fdLIEYfjtsOQXuo9CM4e3vjePtyJYx4UckjeJ/3QtSE=; b=nTycVe4YA1JZccnn1SahW+mae/4t6ipzz5dH0ncetcxZt8BQHRdJ5ECUWMUmAIO4gL 8YMoZSkkTnuyCho/nE2GazvC9fLQXTFB1XqyGcuNHNgsBT8HJGamOC8d//SY+P/MPvQ8 ft85IsvEsOIpfaTJq8Pf0i8WNfTPfgOtW9zBahfXd9DvUVGe6JTlPYd+ulANcf6kWjSF QKHO5QeBoDIrkd+WHkcTFtK/PkF83eytzMt18zRBUirP++r86FSEHYRCcv1AyROzBHO9 nwOdkui7H1qsdfL6diy/D9FWgCwgGR5+0PLJFgkvi/JA/EDu7cKKL657rPV+u5alvHUa Hn1g== 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=fdLIEYfjtsOQXuo9CM4e3vjePtyJYx4UckjeJ/3QtSE=; b=Rg6JZUiRJQAXOAYXdEQR03K0cCFUBxp+4ndlOP2YiWq1QIODiqPz/jEUg3MSY2ATvG 0Q4nUmqf1rj231cyDEVXHLq2BoMzKgfVBt1h7qZ7yBjdDL2sGPoNWM54K2LkY0gAVObD r/B7INlNNpU6ub6b5FPrcl0Gnar0THibsZz0Iu1I+cNhbC5p8Wz8SyK+2jxVXhcxsJet ejqxxfcZLZudvK1gqGN4OBJelg2eAAwZahHPihCW5R5wTcEVaTFP0F28+onsJYltMl+4 PzUWy1yoTeSvum5p9excmwkB90g4ElMaAgYbJsoEaRujLlLoGwMIH8AhVj0PAmLlvRIe 6XWA== X-Gm-Message-State: AOAM5301WsCj+kYzdiogdAJYCTr/SP7vypoYeXuqorZTMghfx055N6aC 5xZOeuXIK6qPUAxYpZI0gSM6okOArXNVVygdpQjLgtGf X-Google-Smtp-Source: ABdhPJylc2u4iQVqrvLDV8Yo4UcIpf94rOvsKMBiCkSkg6WSG8W02uTmPWQ1jWV79h4kSQwMHd7p/ndCI1ADDcDmRoM= X-Received: by 2002:a2e:7215:: with SMTP id n21mr351020ljc.242.1597342910156; Thu, 13 Aug 2020 11:21:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 11:21:14 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be961605acc66086" Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Thu, 13 Aug 2020 18:21:54 -0000 --000000000000be961605acc66086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OAuth 2.0 goal was not to get rid of usernames and passwords. It was to stop site A from asking for the user's username and password at site B so that site A could access resources at site B. How the AS authenticates the User is out of scope, and I think should be out of scope. There are a plethora of authentication mechanisms, and standardizing how the user authenticates is not required for interop. Sharing the "quality" of the authentication is an area of standardization that has been done in OpenID Connect, and I think should be included in GNAP. Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS. =E1=90=A7 On Thu, Aug 13, 2020 at 10:31 AM Denis wrote: > This topic has already been tackled on the list, but I open a new thread > for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since > the solution in OAuth 2.0 was to use access tokens, > there have been used everywhere, even when they were not strictly needed. > > It is also possible to get rid of IDs and passwords using FIDO. FIDO > discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS. > > FIDO should be one allowed possibility for the user authentication. In th= e > case of FIDO, the user is authenticated under a pseudonym > specific to the RS. It may observed that there is no equivalent in OAuth > because of the two different semantics of the subject claim. > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is the subject of > the JWT. The claims in a JWT are normally statements about the subject. > The subject value MUST either be scoped to be locally unique in the > context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two users betwee= n > two RSs (i.e. using a locally unique identifier in the context of the > issuer) > while in the other case (i.e. using a globally unique identifier) it is > possible, in addition, to link the subject claim between one RS and any > other server > (i.e. not supporting OAuth) that is using the same globally unique > identifier. > > None of these two semantics fit with the FIDO use case where the subject > value is scoped to be locally unique in the context of one RS. > Hence, the linkage of users between two RSs (or between one RS and any > other server) becomes impossible. > > There are cases where a user would like to enjoy the unlinkeability > properties of FIDO which cannot be met using the claims currently defined > in OAuth. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000be961605acc66086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OAuth 2.0 goal was not to get rid of usernames and passwor= ds. It was to stop site A from asking for the user's username and passw= ord at site B so that site A could access resources at site B.

How the AS authenticates the User is out of scope, and I think=C2=A0= should be out of scope. There are a plethora of authentication mechanisms, = and standardizing how the user authenticates is not required=C2=A0for inter= op. Sharing the "quality" of the authentication is an area of sta= ndardization that has been done in OpenID Connect, and I think should be in= cluded in GNAP.

Having said that, the Client could= optionally use FIDO to authenticate the User and somehow transmit that to = the AS.

3D""=E1=90=A7

On Thu, Aug 13, = 2020 at 10:31 AM Denis <denis.ietf= @free.fr> wrote:
=20 =20 =20

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0,= one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
and no trust relationships need to be defined since there is no AS.

FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.

RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.=C2=A0 The claims in a JWT are normally statements about the subject.=C2=A0
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally= unique identifier in the context of the issuer)
while in the other case (i.e. = using a=C2=A0globally unique identifier) it is possible, <= span style=3D"font-family:Arial" lang=3D"EN-US">in addition, to link= the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.

None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
Hence, the linkage of users between two RSs (or = between one RS and any other server) becomes impossible.=C2=A0

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000be961605acc66086-- From nobody Thu Aug 13 11:25:42 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 3FB3A3A0F7B for ; Thu, 13 Aug 2020 11:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=prodigy.net 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 AGz_Uv-th_Gw for ; Thu, 13 Aug 2020 11:25:39 -0700 (PDT) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 405593A0E01 for ; Thu, 13 Aug 2020 11:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597343137; bh=IaOr4Yt7YMcqY5BS1UW8T8O7kpOIHSReAy5/52LBfpE=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=b3QtgcR4s/rihb8BZfSqIdZXuZr7Gw2uoX02sjBe01Ete7OuaY4Nfl/3CXRTakgdfHEm0SceOUaMM9+Xfcpg5nB/NDpbwI1DpXuh3viWxD1pibS5lee1gk13SPUbPIcEkX8i2c04OJWA+BTI/zLXWthnOUgLAbjLnwwTQt7zDY5tRA+QI90f8uIGEj/7JnUp5VuWWMxWDvFL26/KyUQX4RAY0S5sym7yfMDZ+i2nYSINnFWk3JDJ2xBbfzOaQBXvWbqV33Lz1upJx6u9SQ0jnDjPcSZumt5GR3ZGM9oQgJK+V4YxJ9zq5ZxQQLmmNO3aTnqQ9VioMlGrZg3Omjk7Ag== X-YMail-OSG: fJRGV8MVM1kkOMdH6ZjcNAVPA08LR3cLe6SFfw7EXDj.nHhtxFqYIfEranI.Da6 frq_bQkPsyz4BfWB7CV5MMg_UOI8Qf9BemRDy6HgBkTf_216gbMTXKct1xluIzrlbI9vsSviOw38 i8C6wm8xX_G3QfWGAngspv0Geb6zHwoeAH2hkgw0RznRfhhTUNVYet8IsFMFcmhlinB_HgYk3jBN _C1vZeptj6Q67L0kiT.cave9cmwIkByMP1wg53ffi6mSEv3o5c6nzpgjbXLXzZ8duGZofJLxoBs3 n2pobDhtuaiJxQ652AyCNEMi2eqqeFTkntqDyMZG6MgeosvjjFSenLVQffdOcly9DOzl6f9p2fUW btsGB8Pe1DuMN0ECOph4I6MjwrBOp4q6AAPSIsQpDeNSk_RnY5jUPsIWkhWVwXrgVJvBSm1KHukD YRt8OxLisOIDVEPDDv7R2ZWH9AoL5Bsyc0bVNieULyeBEjARlRUcoT51m0ZowIgHKaWg242_u5bq Y9eYLRsaL0XuYGLZunmc8rciUUn2_CbQHA6Td0RWvplU9Whob4txjmeUn0Wwdjx_IUGhbzgB.WlF 3t8WQCMopIlzQZrKbLECJz7uDNyb73BjjbpTKAuBAbem.yGlhOZm4.0IcIG_vXFD7jTKZFg2nwyM Q983T0Nd.q3ByTGAWlRG55LCZTHfTiaDdH8S6RzdFk6RNckaZo1xe1SrMoqCKPGcXRvakvbrobVj brFcBWhYy6Lsw1pRaqkKIAOzcrhgfsiP5Vn5azUCNDhetcRNkbompoXoh4pRVr0mqpn5vIvpazIt XO0xmfxn9WvLq4xEhfoW29oXQVMU5E63DI1H1If5e2mHksi92XdHwLKcfQY0kOZQtKBverMlwjaT KOiBDpghExBd51iW7AN21KL134E6PWfne62sw9RG8MCzXkAMqxQtCwHRWpjjEnE2V5ViXr9i9sJ8 KkvMoY9HE6ZW5FUk5E7_cEPw5dznmjDLcGfnfC0xy4r9Gu7CEbGkvVIwvRu7OVSb4lJy8fKJl7Vk MdWwB_gwSkOyL_JvShzuYFckg85qaDG2acJ.q8qbO8PsIoLKuhHSOKgBwyY7tcrvSXWUT9UVBEaA J5VCc1gomTe_2PflGXINsCh9qtCJHcTZvzHo.RRTcg2Vlpmn1Dw1hQJ7kCaXg9Xpfald_w5eb0n5 LMEsaQbLq4BaZqFmuIKf3BHvhX6DUxIJkUkPzvApLzbTW8s.fzK9ciuECiTzx_nRuaJ4JDsvpY8A 5j2NWqXmkC9LJ_0Bew4vpSQp7sntUYKaVX9g6imjHYKTV5j.OCuzWxIhYJx415gEor8mHrXdEeB1 FVLsGW6ih5y_aoaNBjXSGN4XbzQ2kQOy9Hf142aAv9Z4MjzSDdKs7R.lX0v_un1nxA5foXj2Xc3x d18k.VKe5m4hKtxdPflJSQrl36opQ2nG4knY20wU_xcbsOeouEbbb5OcHKdfcLRlDYFVChMYHIet 1XsQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Thu, 13 Aug 2020 18:25:37 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e2bf197c4f79239591fa5270ff90836b; Thu, 13 Aug 2020 18:25:34 +0000 (UTC) From: To: "'Denis'" , References: In-Reply-To: Date: Thu, 13 Aug 2020 11:25:32 -0700 Message-ID: <018901d6719f$22593a20$670bae60$@prodigy.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018A_01D67164.75FBE8C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrKl/KwmA Content-Language: en-us Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Thu, 13 Aug 2020 18:25:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018A_01D67164.75FBE8C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dennis, not all the way correct =20 * It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D = PII, there can be all sorts of information passed in ClientData field of = the FIDO response, not desirable but perfectly OK =20 * None of these two semantics fit with the FIDO use case where the = subject value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible =20 There is nothing that prohibits the RS from sharing registration = information between RS=20 =20 From: TXAuth On Behalf Of Denis Sent: Thursday, August 13, 2020 10:31 AM To: txauth@ietf.org Subject: [GNAP] Support of FIDO =20 This topic has already been tackled on the list, but I open a new thread = for it. In OAuth 2.0, one of the goals was to get rid of IDs and passwords. = Since the solution in OAuth 2.0 was to use access tokens,=20 there have been used everywhere, even when they were not strictly = needed.=20 It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS.=20 FIDO should be one allowed possibility for the user authentication. In = the case of FIDO, the user is authenticated under a pseudonym=20 specific to the RS. It may observed that there is no equivalent in OAuth = because of the two different semantics of the subject claim. RFC 7519 states: The "sub" (subject) claim identifies the principal that is the subject = of the JWT. The claims in a JWT are normally statements about the = subject. =20 The subject value MUST either be scoped to be locally unique in the = context of the issuer or be globally unique. In one case, it is possible to link the subject claim of two users = between two RSs (i.e. using a locally unique identifier in the context = of the issuer)=20 while in the other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server=20 (i.e. not supporting OAuth) that is using the same globally unique = identifier. None of these two semantics fit with the FIDO use case where the subject = value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible. =20 There are cases where a user would like to enjoy the unlinkeability = properties of FIDO which cannot be met using the claims currently = defined in OAuth. Denis ------=_NextPart_000_018A_01D67164.75FBE8C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dennis, not all the way correct

 

  • It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
    and no trust relationships need to be defined = since there is no AS

=

Depends on if you only consider = =E2=80=9Cprivate information=E2=80=9D PII, there can be all sorts of = information passed in ClientData field of the FIDO response, not = desirable but perfectly OK

 

  • None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.
    Hence, the linkage of users between = two RSs (or between one RS and any other server) becomes = impossible

 

There is = nothing that prohibits the RS from sharing registration information = between RS

 

From: TXAuth = <txauth-bounces@ietf.org> On Behalf Of = Denis
Sent: Thursday, August 13, 2020 10:31 = AM
To: txauth@ietf.org
Subject: [GNAP] Support of = FIDO

 

This topic has already been = tackled on the list, but I open a new thread for it.

In OAuth = 2.0, one of the goals was to get rid of IDs and passwords. Since the = solution in OAuth 2.0 was to use access tokens,
there have been used = everywhere, even when they were not strictly needed. =

It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
and no trust relationships need to be defined = since there is no AS.

FIDO should be one allowed = possibility for the user authentication. In the case of FIDO, the user = is authenticated under a pseudonym
specific to the RS. It may = observed that there is no equivalent in OAuth because of the two = different semantics of the subject claim.

RFC 7519 = states:

The "sub" (subject) = claim identifies the principal that is the subject of the JWT.=C2=A0 The = claims in a JWT are normally statements about the subject.=C2=A0
The = subject value MUST either be scoped to be locally unique in the context = of the issuer or be globally = unique.

In one case, it is possible to = link the subject claim of two users between two RSs (i.e. using a = locally unique identifier in the context of the issuer)
while in the = other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server
(i.e. not supporting OAuth) that is using the same = globally unique identifier.

None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.
Hence, the linkage of users between = two RSs (or between one RS and any other server) becomes = impossible. 

There are cases where a user = would like to enjoy the unlinkeability properties of FIDO which cannot = be met using the claims currently defined in = OAuth.

Denis

------=_NextPart_000_018A_01D67164.75FBE8C0-- From nobody Thu Aug 13 11:27:34 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 EA8C43A0F98 for ; Thu, 13 Aug 2020 11:27:32 -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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=prodigy.net 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 8bxeHF-aBaz0 for ; Thu, 13 Aug 2020 11:27:31 -0700 (PDT) Received: from sonic314-19.consmr.mail.bf2.yahoo.com (sonic314-19.consmr.mail.bf2.yahoo.com [74.6.132.193]) (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 F0BE63A0F96 for ; Thu, 13 Aug 2020 11:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597343248; bh=m0Stcz7kVcXhvcBi5G5dWwJuFL+r/dCB3gNMmgnQBsY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From:Subject; b=DLkv5CJR9xLZcv9RSHww+DLi2hgoPP3nrMwbSR6pxm92guRjSyT0ZV1ditSFI0+hk375XfwdQgzRnNZo06gCCCQMBrcWKDOFYknGGuA8pSao929pP4h/95ceSB19Q9JSHRx1OcCfdM86NRTusNeIJFNcBwN2DiR78S3V0NxujyQGMTU9NUDXZoKH3bkPxYPStIZUOJTg/OWvJNk5LRXNnj1W8HzZ81sTTfb6YCeEPfalXMtPPG8tirEB2TAzF1VWgkQUQEXAkqedko8Ml0sVANXavDFpwMyqdGgfEglBy1pWCx76WU72MGXPJwtVFIQtOXA7ZBsbri1lFNncb35uag== X-YMail-OSG: xyvRa0EVM1mjIBhN.bJ631EZvT60AGFylZkC.xHWykeODsi52fBoEhmloOssVqK K4Fsq5KPJoqlBX10s.rJfm9keHkUMYTJbBXuqbSo5OWOrVQiljWH7L1yXI4ZaqBrcvbZFoKzHJAQ JpPfJT.rldwe5XnUBGs2sBvhTT3QXvASUWzg.qk9nwSlYAC.neQBket_zt4QG9uM_LKpIW2i9ou5 2lfgrrShaR8Wgc3g6Ln.PPfX0th0XSloIHp2fscNBwXT85wbXBJZ9X2GF6zI1oa5xWzPc6gjw08P xWG5RP6g..ghfY66wEQYwy0wZ0CDv7KEXFCu0OnNoY1qg5lRxMwBwj6IWNSp5l3fvNHu5miLpS.7 ecse8qa7qEbP8q6cmcSliRgh3889KudY..87PwGTNFUFOTzgP24Ekw4TwIAreawqRzbs96iKXOet ZfnYQ7144S5Em2GwDTzc69THBFPfjLZeGilfoLfjobhXQLT.7WcUDbihtMhkl7SZ.R7cpJlw_aNd 4U9DpTIbUYQmOBTzydruEamdGru9tZBDhB7hShf3nzGD0ZD8In14uxEEAFxb._LxNlWuE1b0VtdA 9eSMXzW1By6jZqLaRkmzLovRb8O9iWEiFIBTcLomCFKywGhjAple8sVeHWei21pX9c2weBxBcqJu tRgW8PWgM3uHzcNRxHrKz_vQn6G45ebdLAVYiv3I_KTkYXEwWOmaIS1yED.t_wggldaLRg_m6KUx tMHskWT960l5OOHGo.wc9SromjewBloGx_aQQeKbd7p0AJfffYEZcVYjItf22nhfKlAu_znZikEl rZMu_C9QqKMcSLBB4dS85z5KWPRRu1d2eFwKal6jiNw7OPTlHqSg1UV4X264Zy1Xp91YfI541spX b2zz2mYgSAnvx1bwAoAZSCvknrr36wqVTTl3BYlPvhQ_2lI6W4tipCm7GZn7DlHpAS8H3lYUkerR 6kuc9raIJgwVT4AHOrpJncaKMTqxQBMjIj6wijX10ZvposJvVGdm82fej_BQY4G_UlNHqOP9l02i m2wRcRznj5uADzjR6y3FYlxGVXeIKag73fJOWVLp0JiF4_er.NFEeTAPUrk0b0XAl6RT5UR86D2z Fgzln72E5arssRTXatmXNAyTLY4W0RRipGuaDJ3mZTeNut6jMhPpABUU7aMKHD1vtUs9HWKImesR yAw5KZzw4QhlhvKIZBAupp82Dtmk.70OuuIVnqjBrwJwblXSs.BUZme.KXp0sMh_bseeMd0Mkoem Lm7OOIz8AqeQ.nLRY7x8dFKtwbmfXRrwlOQ6RfUJe7H0xA05wTTz.8Bre6gm8yxx7Q.XVdFdGf9e OQpDw1io2smOsFTAvkJw06qqZXx_s3P.WE1rEIS_Ok96nfjWLPZrfyPEpc4K0vQq63C5MzLj2nU6 KkTsGpVpua7RU7sPTNYbbCcf3lYmuCKT3ymPquvWfHYyzMSdCLCPIXKqJpgl90NjP_nX88XXoJLf j0l806x8E9Nu5eRUfCE8P Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Thu, 13 Aug 2020 18:27:28 +0000 Received: by smtp425.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d8e4a64036633f4ad9e4407abe0cdd41; Thu, 13 Aug 2020 18:27:27 +0000 (UTC) From: To: "'Dick Hardt'" , "'Denis'" Cc: References: In-Reply-To: Date: Thu, 13 Aug 2020 11:27:24 -0700 Message-ID: <019b01d6719f$64b76e50$2e264af0$@prodigy.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019C_01D67164.B85A6B10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAKhMFgtqWojPCA= Content-Language: en-us Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Thu, 13 Aug 2020 18:27:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_019C_01D67164.B85A6B10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable * Having said that, the Client could optionally use FIDO to authenticate = the User and somehow transmit that to the AS. =20 Agree, this can be done now, we are also looking at some delegation = mechanisms in WebAuthn to accomplish this=20 =20 From: TXAuth On Behalf Of Dick Hardt Sent: Thursday, August 13, 2020 11:21 AM To: Denis Cc: txauth@ietf.org Subject: Re: [GNAP] Support of FIDO =20 OAuth 2.0 goal was not to get rid of usernames and passwords. It was to = stop site A from asking for the user's username and password at site B = so that site A could access resources at site B. =20 How the AS authenticates the User is out of scope, and I think should be = out of scope. There are a plethora of authentication mechanisms, and = standardizing how the user authenticates is not required for interop. = Sharing the "quality" of the authentication is an area of = standardization that has been done in OpenID Connect, and I think should = be included in GNAP. =20 Having said that, the Client could optionally use FIDO to authenticate = the User and somehow transmit that to the AS. =20 = = =E1=90=A7 =20 On Thu, Aug 13, 2020 at 10:31 AM Denis > wrote: This topic has already been tackled on the list, but I open a new thread = for it. In OAuth 2.0, one of the goals was to get rid of IDs and passwords. = Since the solution in OAuth 2.0 was to use access tokens,=20 there have been used everywhere, even when they were not strictly = needed.=20 It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS.=20 FIDO should be one allowed possibility for the user authentication. In = the case of FIDO, the user is authenticated under a pseudonym=20 specific to the RS. It may observed that there is no equivalent in OAuth = because of the two different semantics of the subject claim. RFC 7519 states: The "sub" (subject) claim identifies the principal that is the subject = of the JWT. The claims in a JWT are normally statements about the = subject. =20 The subject value MUST either be scoped to be locally unique in the = context of the issuer or be globally unique. In one case, it is possible to link the subject claim of two users = between two RSs (i.e. using a locally unique identifier in the context = of the issuer)=20 while in the other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server=20 (i.e. not supporting OAuth) that is using the same globally unique = identifier. None of these two semantics fit with the FIDO use case where the subject = value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible. =20 There are cases where a user would like to enjoy the unlinkeability = properties of FIDO which cannot be met using the claims currently = defined in OAuth. Denis --=20 TXAuth mailing list TXAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/txauth ------=_NextPart_000_019C_01D67164.B85A6B10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
  • Having said that, the = Client could optionally use FIDO to authenticate the User and somehow = transmit that to the AS.

 

Agree, this can be done now, we are also = looking at some delegation mechanisms in WebAuthn to accomplish this =

 

From: TXAuth = <txauth-bounces@ietf.org> On Behalf Of Dick = Hardt
Sent: Thursday, August 13, 2020 11:21 AM
To: = Denis <denis.ietf@free.fr>
Cc: = txauth@ietf.org
Subject: Re: [GNAP] Support of = FIDO

 

OAuth = 2.0 goal was not to get rid of usernames and passwords. It was to stop = site A from asking for the user's username and password at site B so = that site A could access resources at site B.

 

How the AS authenticates the User is out of scope, and = I think should be out of scope. There are a plethora of = authentication mechanisms, and standardizing how the user authenticates = is not required for interop. Sharing the "quality" of the = authentication is an area of standardization that has been done in = OpenID Connect, and I think should be included in = GNAP.

 

Having said that, the Client could optionally use FIDO = to authenticate the User and somehow transmit that to the = AS.

 

=E1= =90=A7

 

On = Thu, Aug 13, 2020 at 10:31 AM Denis <denis.ietf@free.fr> = wrote:

This topic has already been = tackled on the list, but I open a new thread for it.

In OAuth = 2.0, one of the goals was to get rid of IDs and passwords. Since the = solution in OAuth 2.0 was to use access tokens,
there have been used = everywhere, even when they were not strictly needed. =

It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
and no trust relationships need to be defined = since there is no AS.

FIDO should be one allowed = possibility for the user authentication. In the case of FIDO, the user = is authenticated under a pseudonym
specific to the RS. It may = observed that there is no equivalent in OAuth because of the two = different semantics of the subject claim.

RFC 7519 = states:

The "sub" (subject) = claim identifies the principal that is the subject of the JWT.  The = claims in a JWT are normally statements about the subject. 
The = subject value MUST either be scoped to be locally unique in the context = of the issuer or be globally = unique.

In one case, it is possible to = link the subject claim of two users between two RSs (i.e. using a = locally unique identifier in the context of the issuer)
while in the = other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server
(i.e. not supporting OAuth) that is using the same = globally unique identifier.

None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.
Hence, the linkage of users between = two RSs (or between one RS and any other server) becomes = impossible. 

There are cases where a user = would like to enjoy the unlinkeability properties of FIDO which cannot = be met using the claims currently defined in = OAuth.

Denis

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

------=_NextPart_000_019C_01D67164.B85A6B10-- From nobody Thu Aug 13 11:59:46 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 A739D3A105E for ; Thu, 13 Aug 2020 11:59:33 -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 7TdDypWk6e_i for ; Thu, 13 Aug 2020 11:59:31 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 5CEEF3A106E for ; Thu, 13 Aug 2020 11:59:31 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 9so5551897wmj.5 for ; Thu, 13 Aug 2020 11:59:31 -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=VWJkt9+1TILKT8hsutDCrRUbEU/liXYOhDTRZEEX7dk=; b=SrGUMe7baBegjdSV7+ok/o9Spu2dEb0s/pmS1ZyNNvNSyEi4fixgr03IhjEUjklzuO Yq5PdRugQ78y+8caAyBLqDsrk9TYM/NzVAB1SfqRGFnEl+X3sj5kXalqlqB55pj5IrD1 LRpg41kdjv7Xn22TjvrX1/Pd4DzHW6vcYWa/k= 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=VWJkt9+1TILKT8hsutDCrRUbEU/liXYOhDTRZEEX7dk=; b=jmsvaFWu6JoCpasAo4T3VGH6fsNb9GVUXC/vdUYVeLRS16uYfSXaZXSWp1UmyK4/Mh O6U6yH9sp15SkxUHqSHwJyarL/8s7cntuBJ/DRO7GI6eLLDhYfuuJ+zBzF4fs1StP3pf q/oFTJNayC77bu2Zar89KeK2hiJeXhQ1yUhAidHEGclLiM5+ZQxKyud7yWR6GXB52HJB 55wXtN7X9wxIy0fkDrzZJUuonc+7IbZn0A039fhXWRw5MIOMUcx8f0D7vRGw5/zBHIxX 14IHj6E+/lG0DSAFLW/NEApnzbAhFYKdwh1Hgw5o/7xILcygTFlhCmdxGhx/aX3GBV3u RWTg== X-Gm-Message-State: AOAM532OXzFcWa8ut1J/vVE4L4hPsNXPpnHZwA5FFhg4XtO0hL/KjO5M PQetgV7RF0yq/VWBzSZ/b7MaJrtdisHd3Wbg9WmlrQ== X-Google-Smtp-Source: ABdhPJx169ajI/bGbStYjaKTH6QWF+tBxALdVm4/8Gogz3HNPAp9wpd0iZ2f29iuVpmZZkWzGn4TKqKoGzFOf+FfGPo= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr5370072wml.38.1597345169637; Thu, 13 Aug 2020 11:59:29 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> In-Reply-To: <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> From: Francis Pouatcha Date: Thu, 13 Aug 2020 14:59:18 -0400 Message-ID: To: Denis Cc: Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006b9af005acc6e79f" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 18:59:41 -0000 --0000000000006b9af005acc6e79f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lots of mails, so I will summarize my opinion in this single mail: We are dealing with different levels of abstraction here, this is why we are always falling back to wording battles. oAuth2/OIDC vs. GNAP AS vs. GS/DS/IS Entity vs. Roles User (human) vs. Requestor Client vs (Orchestrator/Requesting Party/Negotiator...) front-channel & back-channel To direct the discussion, we have to agree on the level of abstraction at which we want a certain discussion to take place. Abstraction Level-0: GNAP Level-0 deals with roles (participants) and messages (request/responses). Level-0 does not consider entities (users) or the nature of any other participants, neither Level-0 deals with the way a message is transported (synchronous/asynchronous) or the type of interaction used to materialize the message (front-channel, back-channel). The purpose of this abstraction layer is to provide a common understanding of the core elements of the protocol. Level-0 can still provide some basic definition of messages including information schema as long as we are not limiting the protocol with constraints from lower layers. Level-0 is ideal to address some fundamental privacy and confidentiality matters that will be materialized in lower layers. Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC] Instantiation of Level-0 for a constrained application space. This is why we will meet the world Client, User, RO, AS, ... here roles defined in Level-0 will be mapped to entities, interaction will be used to materialize messages defined in Level-0. The protocol mapping at this layer also takes into consideration that some of those participants are human or only pieces of software, running on the user device or on a server with consequences on the protocol design. Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / ... In Summary: Level-0: Roles, Messages Level-1: Entities, Interactions ... And if it happens we want to define GNAP at Level-1 (instead of 0), let declare it as such and limit the application space before we proceed with further discussions. Best regards. /Francis On Thu, Aug 13, 2020 at 1:30 PM Denis wrote: > Justin, > > Your response does not address my point. I am talking of two different > channels with the RS, i.e. not with the AS. > > Denis > > Denis, I want to focus on one point here: > > In OAuth 2.0, the user consent is performed by the AS using an authorize > endpoint where the user consent is solicited and captured. > > Since a user, with no prior experience, shall first connect to a RS to > perform an operation, the user consent shall be performed by the RS, > instead of the AS. This means that we should define a "consent" endpoint > at the RS. > > > One of my goals with XYZ=E2=80=99s design was to be able to separate the > interaction with the user from the web-based flows for the delegation > protocol, and that aspect is enshrined in the GNAP charter as well. > > It points to the reality that there are two different aspects of the > traditional AS that we might need to talk about separately now. One deals > with delegation, issuing tokens, returning data directly to the client (n= ot > through a separate API, since that=E2=80=99s the RS), and other back-chan= nel stuff. > The other aspect deals with interacting with the user and/or resource > owner. > > We already saw bits of this in OAuth 2: the AS is defined by the pair of > the token endpoint and authorization endpoint, each filling the respectiv= e > roles above. What if we formally separate these? Strawman names: > > Delegation Server (DS) - handles the back-channel stuff > > Interaction Server (IS) - handles the front-channel stuff > > > =E2=80=94 Justin > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000006b9af005acc6e79f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lots of mails, so I will summarize=C2=A0my opinion in this= single mail:

We are dealing with different levels of ab= straction here, this is why we are always=C2=A0falling back to wording batt= les.

oAuth2/OIDC vs. GNAP
AS vs. GS/DS= /IS
Entity vs. Roles
User (human) vs. Requestor
Client vs (Orchestrator/Requesting Party/Negotiator...)
fr= ont-channel & back-channel

To direc= t the discussion, we have to agree on the level of abstraction at which we = want a certain discussion to take place.

Abstracti= on Level-0: GNAP

Level-0 deals with roles (partici= pants) and messages (request/responses). Level-0 does not consider entities= (users) or the nature of any other participants,=C2=A0neither Level-0 deal= s with the way a message is transported (synchronous/asynchronous) or the t= ype of interaction used to materialize the message (front-channel, back-cha= nnel). The purpose of this abstraction layer is to provide a common underst= anding of the core elements of the protocol.=C2=A0

Level-0 can still provide some basic definition of messages including info= rmation schema as long as we are not limiting the protocol with constraints= from lower layers.

Level-0 is ideal to address so= me fundamental privacy and confidentiality matters that will be materialize= d in lower layers.

Abstraction Level-1: OAuth2 / O= IDC / [SSI/DiD/VC]
Instantiation of Level-0 for a constrained app= lication space. This is why we will meet the world Client, User, RO, AS, ..= . here roles defined in Level-0 will be mapped to entities, interaction wil= l be used to materialize messages defined in Level-0.=C2=A0
The p= rotocol mapping at this layer also takes into consideration that some of th= ose participants are human or only pieces of software, running on the user = device or on a server with consequences on the protocol design.
<= br>
Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / = ...

In Summary:
Level-0: Roles, Messages=
Level-1: Entities, Interactions
...

And if it happens we want to define GNAP at Level-1 (instead of 0), = let declare it as such and limit the application space before we proceed wi= th further discussions.

Best regards.
/F= rancis




On Thu, Aug = 13, 2020 at 1:30 PM Denis <denis.i= etf@free.fr> wrote:
=20 =20 =20
=C2=A0Justin,

Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

Denis

=20 Denis, I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. = This means that we should define a "consent" end= point at the RS.

One of my goals with XYZ=E2=80=99s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that=E2=80=99s the RS), and other back-channel stuff. = The other aspect deals with interacting with the user and/or resource owner.=C2=A0

We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

Delegation Server (DS) - handles the back-channel stuff

Interaction Server (IS) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin


--
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/
--0000000000006b9af005acc6e79f-- From nobody Thu Aug 13 12:27:59 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 812153A1080 for ; Thu, 13 Aug 2020 12:27:57 -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 9qzOZwXViR8F for ; Thu, 13 Aug 2020 12:27:55 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 3C8833A107C for ; Thu, 13 Aug 2020 12:27:55 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id v4so7488903ljd.0 for ; Thu, 13 Aug 2020 12:27:55 -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=uuhgUHsBilPQrbEgQVL6RZytHpz0n3uADSegyhSACgg=; b=bnOoxIwA+jfsNgXzLpVxsuF+MYb6XzrgCvjRjjAB2p/cC0335esGjCZZg6ALO35H6x XkjKy9rkEVTiBFqLeoh0YmPsZb8s0P5xK5lQLU2kt1ZtxRCEajUa72Bxp014bP4hIwsM slpjWGcIcXjeR+rKdPrUVJx95cx3Vkwuis9uu2nIr9PzxewFUYxF2EcAdwPz20M4WXCH omFkmgT0FpB2oj33alT/OHnJZYu3AMb6POHTao3lc0A/Xgz0E+DC/qCOAzzYYfCG4lHm QtqZQ34ik0YM+6/nUYEl2iBCbE8eU8fa0ymF9/Kw+zIGkhV65HbJC2Z5MSt3Y3lcD3m1 q92g== 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=uuhgUHsBilPQrbEgQVL6RZytHpz0n3uADSegyhSACgg=; b=atBO7PwTLXn8k0Nb2MZAnR34MerkwX+qQetEjuAqnuAK9PuLeKJ3nfMqB7H+mqWjSC F1nSaveesOEzXhNr9pxg6O7mU7obCgBr/eggrn1/jqMOQ2vkUq7jQnh8i5VwiQQmfIQa iL7YoSCyXScuaBsG0nibJRGUAqt8kaGnFkF+lms/vIIChq65css//aId4IvIoSLylFda SyPAmJ97nmdi2tiQoi93PA6ORkHaAWw6UnL7dz32fyLHBaGsGpRc63mkc7g7TKSAVEWS 7DYml14rjOeJ8NYsm65xgQt0Rs2Dhhmy8w/NuvAngp8SIVOdiIiPQjQ7mZeAuGx3L6P8 LSyw== X-Gm-Message-State: AOAM533Ty5wGfN/S7/aN67Sem3FwiOmUEF1LTjuWZxooYmzYfwAeAV5U P3ynXBE0wgVYwKCPXd3fBYhGuY94fQtl15/WJXo= X-Google-Smtp-Source: ABdhPJy25DJMTRI9VjoNaqsN6u253+gHeytGmXIUn/WGggJWbSvwkwChIr2FcpPu1e/jPjcxkMHCNqr5IhgS1CjbDHM= X-Received: by 2002:a2e:7215:: with SMTP id n21mr468507ljc.242.1597346873167; Thu, 13 Aug 2020 12:27:53 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> In-Reply-To: From: Dick Hardt Date: Thu, 13 Aug 2020 12:27:16 -0700 Message-ID: To: Francis Pouatcha Cc: Denis , "txauth@ietf.org" , Justin Richer Content-Type: multipart/alternative; boundary="000000000000f555ad05acc74c88" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 19:27:57 -0000 --000000000000f555ad05acc74c88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francis I have come to a similar conclusion. I'll be posting my thoughts in a concrete proposal and am keen to hear how it fits into how your mental model. /Dick =E1=90=A7 On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha wrote: > Lots of mails, so I will summarize my opinion in this single mail: > > We are dealing with different levels of abstraction here, this is why we > are always falling back to wording battles. > > oAuth2/OIDC vs. GNAP > AS vs. GS/DS/IS > Entity vs. Roles > User (human) vs. Requestor > Client vs (Orchestrator/Requesting Party/Negotiator...) > front-channel & back-channel > > To direct the discussion, we have to agree on the level of abstraction at > which we want a certain discussion to take place. > > Abstraction Level-0: GNAP > > Level-0 deals with roles (participants) and messages (request/responses). > Level-0 does not consider entities (users) or the nature of any other > participants, neither Level-0 deals with the way a message is transported > (synchronous/asynchronous) or the type of interaction used to materialize > the message (front-channel, back-channel). The purpose of this abstractio= n > layer is to provide a common understanding of the core elements of the > protocol. > > Level-0 can still provide some basic definition of messages including > information schema as long as we are not limiting the protocol with > constraints from lower layers. > > Level-0 is ideal to address some fundamental privacy and confidentiality > matters that will be materialized in lower layers. > > Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC] > Instantiation of Level-0 for a constrained application space. This is why > we will meet the world Client, User, RO, AS, .... here roles defined in > Level-0 will be mapped to entities, interaction will be used to materiali= ze > messages defined in Level-0. > The protocol mapping at this layer also takes into consideration that som= e > of those participants are human or only pieces of software, running on th= e > user device or on a server with consequences on the protocol design. > > Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / .... > > In Summary: > Level-0: Roles, Messages > Level-1: Entities, Interactions > ... > > And if it happens we want to define GNAP at Level-1 (instead of 0), let > declare it as such and limit the application space before we proceed with > further discussions. > > Best regards. > /Francis > > > > > On Thu, Aug 13, 2020 at 1:30 PM Denis wrote: > >> Justin, >> >> Your response does not address my point. I am talking of two different >> channels with the RS, i.e. not with the AS. >> >> Denis >> >> Denis, I want to focus on one point here: >> >> In OAuth 2.0, the user consent is performed by the AS using an authorize >> endpoint where the user consent is solicited and captured. >> >> Since a user, with no prior experience, shall first connect to a RS to >> perform an operation, the user consent shall be performed by the RS, >> instead of the AS. This means that we should define a "consent" endpoint >> at the RS. >> >> >> One of my goals with XYZ=E2=80=99s design was to be able to separate the >> interaction with the user from the web-based flows for the delegation >> protocol, and that aspect is enshrined in the GNAP charter as well. >> >> It points to the reality that there are two different aspects of the >> traditional AS that we might need to talk about separately now. One deal= s >> with delegation, issuing tokens, returning data directly to the client (= not >> through a separate API, since that=E2=80=99s the RS), and other back-cha= nnel stuff. >> The other aspect deals with interacting with the user and/or resource >> owner. >> >> We already saw bits of this in OAuth 2: the AS is defined by the pair of >> the token endpoint and authorization endpoint, each filling the respecti= ve >> roles above. What if we formally separate these? Strawman names: >> >> Delegation Server (DS) - handles the back-channel stuff >> >> Interaction Server (IS) - handles the front-channel stuff >> >> >> =E2=80=94 Justin >> >> >> -- >> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f555ad05acc74c88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis

I have=C2=A0come to a simila= r conclusion. I'll be posting my thoughts in a concrete proposal and am= keen to hear how it fits into how your mental model.

<= div>/Dick
3D""=E1=90=A7

On Thu, Aug 13, 2020 at 12:00= PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
Lots of mails, so I will sum= marize=C2=A0my opinion in this single mail:

We are deali= ng with different levels of abstraction here, this is why we are always=C2= =A0falling back to wording battles.

oAuth2/OIDC vs. = GNAP
AS vs. GS/DS/IS
Entity vs. Roles
User (human) vs. Requestor
Client vs (Orchestrator/Requesting Pa= rty/Negotiator...)
front-channel & back-channel

To direct the discussion, we have to agree on the le= vel of abstraction at which we want a certain discussion to take place.

Abstraction Level-0: GNAP

Le= vel-0 deals with roles (participants) and messages (request/responses). Lev= el-0 does not consider entities (users) or the nature of any other particip= ants,=C2=A0neither Level-0 deals with the way a message is transported (syn= chronous/asynchronous) or the type of interaction used to materialize the m= essage (front-channel, back-channel). The purpose of this abstraction layer= is to provide a common understanding of the core elements of the protocol.= =C2=A0

Level-0 can still provide some basic defini= tion of messages including information schema as long as we are not limitin= g the protocol with constraints from lower layers.

Level-0 is ideal to address some fundamental privacy and confidentiality m= atters that will be materialized in lower layers.

= Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC]
Instantiation o= f Level-0 for a constrained application space. This is why we will meet the= world Client, User, RO, AS, .... here roles defined in Level-0 will be map= ped to entities, interaction will be used to materialize messages defined i= n Level-0.=C2=A0
The protocol mapping at this layer also takes in= to consideration that some of those participants are human or only pieces o= f software, running on the user device or on a server with consequences on = the protocol design.

Abstraction Level-2: Trust Fr= ameworks like IAM / PSD2,FAPI / ....

In Summary:
Level-0: Roles, Messages
Level-1: Entities, Interactions=
...

And if it happens we want to define= GNAP at Level-1 (instead of 0), let declare it as such and limit the appli= cation space before we proceed with further discussions.

Best regards.
/Francis


=


On Thu, Aug 13, 2020 at 1:30 PM Denis <denis.ietf@free.fr> wrot= e:
=20 =20 =20
=C2=A0Justin,

Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

Denis

=20 Denis, I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. = This means that we should define a "consent" end= point at the RS.

One of my goals with XYZ=E2=80=99s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that=E2=80=99s the RS), and other back-channel stuff. = The other aspect deals with interacting with the user and/or resource owner.=C2=A0

We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

Delegation Server (DS) - handles the back-channel stuff

Interaction Server (IS) - handles the front-channel stuff


=C2=A0=E2=80=94 Justin


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


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f555ad05acc74c88-- From nobody Thu Aug 13 18:39:23 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 8400A3A0BE6 for ; Thu, 13 Aug 2020 18:39:21 -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=moneyhub.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 iIZ8GtLC0ui2 for ; Thu, 13 Aug 2020 18:39:20 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 268BE3A0BE3 for ; Thu, 13 Aug 2020 18:39:20 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id t6so3649893pjr.0 for ; Thu, 13 Aug 2020 18:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nYkdryqDvrBR0s4rAoCm4mnMVYuf7mjmywrZX77hKR8=; b=LLMh36rJXwwTz6fbP8k7DGE06+cXWnE83DpivrKShSWsN6ZjuBSunmUpxKETu69wZR g5jzfWPhaDSVlMr5CghmJBE+jBINIrkHB6zb5XCab8N78f2hnjFUPY9Nc8ff2pEM8KzV EQe4vNyJdESJOrRBe0TttHAjJSV7Qu3qgI5d4= 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=nYkdryqDvrBR0s4rAoCm4mnMVYuf7mjmywrZX77hKR8=; b=YBKjNTeNzS8iVF/GpTbCIjDNtvBy5Vy8Pzpyd4gd8wl+exE3l4b0bu1My6wRFnuDIp YxHOv1FUzKScODmQOq/fTvNyB8FAIwFVvLVmoXuHmBE9ePpFqGHBZixvKGaJUX8vT/qJ l7hO06QdQDE0MlC4NUjxBFNXOeoT6xh0qyPkffk8WFFtg7rNGbce+ArsBYjrdEnJtkZa IMdNDmc2pMnr7FpRFP7TSm61APVfzTuH48LWGZXgNyXBzozAiHtJa3tXzbSfcKU+guuQ 8NGdK0VcMlHIMxNjJYZQZxqCQmaHgPvzxg4ujUBPhMJAGwrrIsO3j7Xqkjb6S39DjpjZ puOg== X-Gm-Message-State: AOAM533Vb2pc5luUHfkLzMKKGqX7nkFjUzfzjUS2yNU+y8Qmm72TTogd Zl9NGrAbDi1amMRMxTub102qSULK2DFV8rmicSx8Gep3guB4Me/YowMhrkDIZDzxP2xiQ2tU32Y HtGYcOKhnI2ksdB0= X-Google-Smtp-Source: ABdhPJwEdp5SNyY5JBEZSDQ/ISnmLbW5kFDCCyEqiwMpb/mmRBBr8KJTAAT6epZhl/nDXiIhs+8RyJMaR24HaDAQ+Yc= X-Received: by 2002:a17:90a:1a42:: with SMTP id 2mr367802pjl.16.1597369159428; Thu, 13 Aug 2020 18:39:19 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> In-Reply-To: From: Dave Tonge Date: Fri, 14 Aug 2020 03:39:08 +0200 Message-ID: To: Dick Hardt Cc: Fabien Imbault , Francis Pouatcha , Denis , "txauth@ietf.org" , Justin Richer , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000052ccf705accc7d2f" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Fri, 14 Aug 2020 01:39:22 -0000 --00000000000052ccf705accc7d2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I agree with clearly separating the GS interaction with the Client from the interaction with the User. > I'm having a hard time viewing those as two different roles. They are two different interactions. Just as the client interaction with the AS is different from the client interaction with the GS. I also struggle to see these as different roles - they seem to be fundamentally linked, However what I think does need to be taken into consideration is that there may be multiple Grant Servers involved in a user flow (I've added a new use case to describe some of these flows: https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers= -in-a-single-flow ) --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --00000000000052ccf705accc7d2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I agree with clearly separating the GS interaction with = the Client from the interaction with the User.=C2=A0

> I'm having a hard time viewing those as= two different roles. They are two different interactions. Just as the clie= nt interaction with the AS is different from the client interaction with th= e GS.

=
I also struggle to se= e these as different roles - they seem to be fundamentally linked,=C2=A0
However what I thi= nk does need to be taken into consideration is that there may be multiple G= rant Servers involved in a user flow (I've added a new use case to desc= ribe some of these flows:=C2=A0https://github.com/ietf-wg-gnap= /general/wiki/Multiple-Authorization-Servers-in-a-single-flow)


Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


--00000000000052ccf705accc7d2f-- From nobody Thu Aug 13 23:29:17 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 919943A0D74 for ; Thu, 13 Aug 2020 23:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 uHk9YPCZKMnY for ; Thu, 13 Aug 2020 23:29:13 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 BA4443A0044 for ; Thu, 13 Aug 2020 23:29:13 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id p18so3761340ilm.7 for ; Thu, 13 Aug 2020 23:29:13 -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=wpO8N3qDaFPFbAWWSudJ6MXVMmea53SRqWSxKPokgWI=; b=eHTqMkusgQZxweLqTyLooBOTgS+KBtlOrKJfuEKywAFA/CWJK6zO1UNbMLX8e4JfE0 76FjhBKszOPnStVMb5Zsr2XOXrhmtOIpkKv/EhO9uJukogGWXn3eOl09kuczCQ2S3xop YOTjzWRCZtQ4br0zlxTakaLBQjGP6Sz4cY2cc1H/efRwyWYMTlMTPKPQRplawFOI4yH7 S8gD4P6ccowe9IBwuABPesVblfXSucl3AliZrE/GInOwmgFSxiyVZ0Lq94vG06B07Iuz TIunrL3ETxtL0a0gqyYsg6bXcz8CdkVSA2wYPFS2+3uv/vGer8qukE9o6pyljnt3+6Hy gX9A== 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=wpO8N3qDaFPFbAWWSudJ6MXVMmea53SRqWSxKPokgWI=; b=uSPYVO+5opN2Urtchl68Pgf2qmcOpIPrv9yeuTIYFEWGRX6vCVySS/CssCCgfbRheW n/QIZTv9vwYPcuHlpwMdP69vnlN1QY/rAEOLYXFIw97LO9BD5KlNDVNfWQup03trij0b OCurkzcNAnrfOpw0qkxSxaeftCubJNgl3G6/CCQkCNQl/Ke3DpauvuFvtkGemEmTiBtk 8U+pTiVfrEdBudGIdjXTojmGHcGKonyNeE+5zz0PbQC8jn+EgsRDr6Ve7dv/yEpF4TQ1 XcFCIVmmQgaP8Jw7WRpQPGDhE6qBXbG0pSTRnOzraRueowXLbrf9safbYSPh04zwYd4a Xqvg== X-Gm-Message-State: AOAM532uT8BTExQ5pR7CqZzIkBf//eVUwCerV9L44w6f0YGMQCOs9zMe f1Fyxy/dSU4w6k7tNyHY1+divyQ2SYoK3phyL8I= X-Google-Smtp-Source: ABdhPJw+MKZ1/min6pGpH/kQo6A5hkkOTrLz/4IzI4Nnlq6Hq8AwSSOnhl3wIkxPOiLdFO0uhYv4Jd8jHMnAszeRIhY= X-Received: by 2002:a92:480f:: with SMTP id v15mr1195210ila.123.1597386553031; Thu, 13 Aug 2020 23:29:13 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> In-Reply-To: From: Fabien Imbault Date: Fri, 14 Aug 2020 08:29:01 +0200 Message-ID: To: Dave Tonge Cc: Dick Hardt , Francis Pouatcha , Denis , "txauth@ietf.org" , Justin Richer , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000010043a05acd08ab0" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Fri, 14 Aug 2020 06:29:16 -0000 --00000000000010043a05acd08ab0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, that's an important use case. Should add DID also. This raises additional questions related to claim aggregation though, in case you have contradictory information. Le ven. 14 ao=C3=BBt 2020 =C3=A0 03:39, Dave Tonge a =C3=A9crit : > > I agree with clearly separating the GS interaction with the Client from > the interaction with the User. > > > I'm having a hard time viewing those as two different roles. They are > two different interactions. Just as the client interaction with the AS is > different from the client interaction with the GS. > > I also struggle to see these as different roles - they seem to be > fundamentally linked, > However what I think does need to be taken into consideration is that > there may be multiple Grant Servers involved in a user flow (I've added a > new use case to describe some of these flows: > https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Serve= rs-in-a-single-flow > ) > > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > --00000000000010043a05acd08ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, that's an important use case. Should add= DID also.=C2=A0

This ra= ises additional questions related to claim aggregation though, in case you = have contradictory information.

Le ven. 14 ao= =C3=BBt 2020 =C3=A0 03:39, Dave Tonge <dave.t= onge@moneyhub.com> a =C3=A9crit=C2=A0:
> I agree with clearly separating the GS intera= ction with the Client from the interaction with the User.=C2=A0

> I'm having a hard time viewi= ng those as two different roles. They are two different interactions. Just = as the client interaction with the AS is different from the client interact= ion with the GS.

I also str= uggle to see these as different roles - they seem to be fundamentally linke= d,=C2=A0
However= what I think does need to be taken into consideration is that there may be= multiple Grant Servers involved in a user flow (I've added a new use c= ase to describe some of these flows:=C2=A0https://github.com/ietf-w= g-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow)


Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financ= ial Technology is registered in England & Wales, company registration n= umber 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub = Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0<= /font>

DISCLAIM= ER: This email (including any attachments) is subject to copyright, and the= information in it is confidential. Use of this email or of any information= in it other than by the addressee is unauthorised and unlawful. Whilst rea= sonable efforts are made to ensure that any attachments are virus-free, it = is the recipient's sole responsibility to scan all attachments for viru= ses. All calls and emails to and from this company may be monitored and rec= orded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company.


--00000000000010043a05acd08ab0-- From nobody Fri Aug 14 03:02:46 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 87E283A0AE5 for ; Fri, 14 Aug 2020 03:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hZlGRw0_UBcN for ; Fri, 14 Aug 2020 03:02:41 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6513A0ADA for ; Fri, 14 Aug 2020 03:02:40 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d41 with ME id FN2d230022bcEcA03N2d9z; Fri, 14 Aug 2020 12:02:39 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 12:02:39 +0200 X-ME-IP: 90.79.51.120 To: Fabien Imbault Cc: Dave Tonge , Justin Richer , Dick Hardt , Mike Jones , Tom Jones , Francis Pouatcha , Benjamin Kaduk , "txauth@ietf.org" References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> From: Denis Message-ID: <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> Date: Fri, 14 Aug 2020 12:02:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FAB95DA71BC7560FE17AD0F6" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology 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: Fri, 14 Aug 2020 10:02:45 -0000 This is a multi-part message in MIME format. --------------FAB95DA71BC7560FE17AD0F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, Thank you for your inputs, a ball is finally rolling. > An attempt. I would add upfront: User =  human person > / = application that requests access to Resource Servers (RS) > through a Grant Server (GS). / > Examples: a web server, a browser-based app, a mobile app, an IoT device. A few explanations: "through" does not sound appropriate since it could be interpreted as the GS being necessarilly placed between the Client and the RS.                                       In addition, more than one GS may be necessary. My proposal: / = application that requests access to Resource Servers (RS) ///on behalf of a User /by using one or more Grant Servers (GS) / /Examples: a web server, a browser-based app, a mobile app./ > /GS = computing service that manages the grant lifecycle to a > on behalf of a Resource Controler (RC)./ > Note : for privacy reasons, the GS may be issuing grants without > knowledge of which resources are requested. I dislike "/on behalf of a Resource Controler (RC)/". The GS may be fully ignorant of the existence of the RSs and hence of the RCs. In addition, "/grant life cycle/" is undefined./ / My proposal: //GS = /server issuing access tokens to a Client after successfully authenticating the User/ /Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested. Note 2: a GS is able to disclose to a User the User attributes that it manages. / > /RS = computing service that grants access only if its Resource > Controler (RC) consents./ > Note : the consent may involve a human interaction or may be automated > based on access control policies. I dislike "/its Resource Controler (RC) consents" /because it may let think that a human person always needs to consent. My proposal: /R//S = server hosting protected resources, capable of accepting and responding to protected resource requests                                   when access tokens are being used/ > /RC = entity which is controlling the access to a protected resource. / > Note : a RC may be manually operated by a human or delegated to a > machine, partially or completely. A RC is not an entity but a function. I would also place the machine case first. My proposal: /RC = function tightly coupled with a RS which controls the accesses to a protected resource /                        Note : the function may be operated either by a machine or by a human person or by some combination of both. > /Consent = the process of asking a RC to accept or decline based on a > grant request presentation, resulting in either a “yes” or “no” > consent decision./ I would instead speak of the "User Consent". The User Consent is a set of choices among a proposed set of choices. It is not simply a "yes" or "no" consent decision. My proposal: /User Consent = ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens/ Denis > Fabien > > On Thu, Aug 13, 2020 at 3:55 PM Denis > wrote: > > Fabien, > > IMHO, nothing is wrong with keeping "Client" since it has a wide > spread usage > ... but only as long as we can agree on a short and a clear > definition for it. > > I can provide the beginning of such a definition: " application ..." > > If someone could go a little bit further, this would help. :-) > > A similar argumentation for GS. It could be used but only as long > as we can agree on a short and a clear definition for it. > Any proposal ? > > Denis > >> Hi, >> >> Nothing inherently wrong with Client/AS, which has worked for >> years in the context of OAuth2. The question is to know whether >> we can build the new protocol with the same concepts and deal >> with their known limitations, or if we're better off with more >> adapted concepts less prone to misunderstandings. >> >> Verb vs Noun: >> Problem is that the grant (noun) can only be understood if there >> is a grant(verb), i.e. some action that grants something. >> The grant (noun) definition directly derives from the verb : >> "something granted ..." >> >> I personally have no issue even with the fairly convoluted "The >> Grant Server issues a grant to the Grant Client representing >> access that has been granted" (except perhaps from the word >> Client, but that's a different issue). >> By the way, grant is nothing new, it's used extensively in OAuth2 >> as "grant types" (whatever that means). >> >> Dick summarized well the reasons why he uses GS instead of AS : >> 1) "grant" is in the working group name (a weaker reason, but >> still has been approved). Question: would our reasoning if the >> protocol ended up being called OAuth3? >> 2) grant = larger in scope than AS (not only authorization), as >> it at least includes idclaims + other use cases like payment (?) >> - no consensus, see difference in appreciation between Justin and >> Dick >> >> As for "Client", if most people think it is problematic, it seems >> a good reason to change if we find a better alternative. >> Quoting Dick again: "The confusion in my experience usually stems >> from people working with software that is acting in >> multiple roles. IE, the software that is acting as a client in >> once context, is also acting as an RS in other contexts, or even >> acting as an AS. The other confusion is that people view >> clients as being the software the user is using -- although it >> may not be acting as a client in the oauth context." and later "I >> do agree that it is not the best term in GNAP. Primarily because >> GNAP is a combination of the client from OAuth 2, and the relying >> party from OIDC." >> >> So far there's no consensus however, recent tries: Initiating >> Application (Denis), Orchestrator (Francis). >> >> Cheers >> Fabien >> >> >> >> >> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >> > wrote: >> >> I would be against using "grant" as both a verb and a noun >> and stick purely with one or the other. (In the charter the >> only use of "grant" is in the verb: "granted"). >> >> Using it as both a verb and a noun will be confusing and less >> accessible. >> >> I think it will be confusing to say "The Grant Server issues >> a grant to the Grant Client representing access that has been >> granted" >> >> Whether the access takes place via a token being returned and >> used at a resource server, or "claims" that are directly >> returned from the "Grant Server" I think should be largely >> irrelevant when it comes to the naming of the roles. >> >> In almost all use cases that I have seen the "Grant Server" >> is making a policy based decision "to grant" access to >> requested resource(s). To me, that is the fundamental >> operation happening. I think nearly all use cases can be >> applied to that, e.g. the GS grants access to >>  - identity attributes for the end user >>  - verify an identity attribute (e.g. that user is over 18) >>  - all users photos at resource server X >>  - a single photo with id 12345 at resource server Y >>  - resource of type X at any resource server that trusts the >> Grant Server >>  - call a payment API with specific properties (e.g. amount < 5) >>  - call a file storage API >>  - call a "contract signing" API with specific properties >> (e.g. contract hash of xxx,) >> While "client" is problematic, it does now have wide spread >> usage, so perhaps we are stuck with it. >> However I agree with Justin and think "Grant Client" makes >> things more confusing. >> >> What is wrong with keeping "Client" and "Authorization Server"? >> >> Dave >> >> >> >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial >> Technology Limited which is authorised and regulated by the >> Financial Conduct Authority ("FCA"). Moneyhub Financial >> Technology is entered on the Financial Services Register (FRN >> 809360) at https://register.fca.org.uk/. Moneyhub Financial >> Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology >> Limited 2020 © Moneyhub Enterprise, Regus Building, Temple >> Quay, 1 Friary, Bristol, BS1 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject >> to copyright, and the information in it is confidential. Use >> of this email or of any information in it other than by the >> addressee is unauthorised and unlawful. Whilst reasonable >> efforts are made to ensure that any attachments are >> virus-free, it is the recipient's sole responsibility to scan >> all attachments for viruses. All calls and emails to and from >> this company may be monitored and recorded for legitimate >> purposes relating to this company's business. Any opinions >> expressed in this email (or in any attachments) are those of >> the author and do not necessarily represent the opinions of >> Moneyhub Financial Technology Limited or of any other group >> company. >> >> > --------------FAB95DA71BC7560FE17AD0F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Fabien,

Thank you for your inputs, a ball is finally rolling.

An attempt.
I would add upfront: User =  human person
<Client> = application that requests access to Resource Servers (RS) through a Grant Server (GS).  
Examples: a web server, a browser-based app, a mobile app, an IoT device.

A few explanations: "through" does not sound appropriate since it could be interpreted as the GS being necessarilly placed between the Client and the RS.
                                      In addition, more than one GS may be necessary.

My proposal:  <Client> = application that requests access to Resource Servers (RS) on behalf of a User by using one or more Grant Servers (GS)
Examples: a web server, a browser-based app, a mobile app.

GS = computing service that manages the grant lifecycle to a <Client> on behalf of a Resource Controler (RC).
Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested.

I dislike "on behalf of a Resource Controler (RC)". The GS may be fully ignorant of the existence of the RSs and hence of the RCs.
In addition, "grant life cycle" is undefined.

My proposal:  GS = server issuing access tokens to a Client after successfully authenticating the User
Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested.
Note 2: a GS is able to disclose to a User the User attributes that it manages. 

RS = computing service that grants access only if its Resource Controler (RC) consents.
Note : the consent may involve a human interaction or may be automated based on access control policies.
I dislike "its Resource Controler (RC) consents" because it may let think that a human person always needs to consent.

My proposal: RS = server hosting protected resources, capable of accepting and responding to protected resource requests
                                  when access tokens are being used
RC = entity which is controlling the access to a protected resource. 
Note : a RC may be manually operated by a human or delegated to a machine, partially or completely.

A RC is not an entity but a function. I would also place the machine case first.

My proposal: RC = function tightly coupled with a RS which controls the accesses to a protected resource
                        Note : the function may be operated either by a machine or by a human person or by some combination of both.

Consent = the process of asking a RC to accept or decline based on a grant request presentation, resulting in either a “yes” or “no” consent decision.

I would instead speak of the "User Consent". The User Consent is a set of choices among a proposed set of choices. It is not simply a "yes" or "no" consent decision.

My proposal: User Consent = ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens

Denis


Fabien

On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr> wrote:
Fabien,

IMHO, nothing is wrong with keeping "Client" since it has a wide spread usage
... but only as long as we can agree on a short and a clear definition for it.
I can provide the beginning of such a definition: " application ..."

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.  It could be used but only as long as we can agree on a short and a clear definition for it.
Any proposal ?

Denis

Hi,

Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings.

Verb vs Noun:
Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something. 
The grant (noun) definition directly derives from the verb : "something granted ..."

I personally have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perhaps from the word Client, but that's a different issue).
By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types" (whatever that means). 

Dick summarized well the reasons why he uses GS instead of AS : 
1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
2) grant = larger in scope than AS (not only authorization), as it at least includes idclaims + other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick

As for "Client", if most people think it is problematic, it seems a good reason to change if we find a better alternative. 
Quoting Dick again: "The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context." and later "I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC."

So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis). 

Cheers
Fabien




On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I would be against using "grant" as both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant" is in the verb: "granted").

Using it as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted"

Whether the access takes place via a token being returned and used at a resource server, or "claims" that are directly returned from the "Grant Server" I think should be largely irrelevant when it comes to the naming of the roles.

In almost all use cases that I have seen the "Grant Server" is making a policy based decision "to grant" access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
 - identity attributes for the end user
 - verify an identity attribute (e.g. that user is over 18)
 - all users photos at resource server X
 - a single photo with id 12345 at resource server Y
 - resource of type X at any resource server that trusts the Grant Server
 - call a payment API with specific properties (e.g. amount < 5)
 - call a file storage API
 - call a "contract signing" API with specific properties (e.g. contract hash of xxx,)
 
While "client" is problematic, it does now have wide spread usage, so perhaps we are stuck with it. 
However I agree with Justin and think "Grant Client" makes things more confusing.

What is wrong with keeping "Client" and "Authorization Server"? 

Dave




Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.




--------------FAB95DA71BC7560FE17AD0F6-- From nobody Fri Aug 14 03:04:18 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 0CAB43A0E74 for ; Fri, 14 Aug 2020 03:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xjtCy0IgzMzO for ; Fri, 14 Aug 2020 03:04:14 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84373A0E7B for ; Fri, 14 Aug 2020 03:04:13 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d41 with ME id FN4A230052bcEcA03N4BHD; Fri, 14 Aug 2020 12:04:11 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 12:04:11 +0200 X-ME-IP: 90.79.51.120 To: nadalin@prodigy.net, txauth@ietf.org References: <018901d6719f$22593a20$670bae60$@prodigy.net> From: Denis Message-ID: <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> Date: Fri, 14 Aug 2020 12:04:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <018901d6719f$22593a20$670bae60$@prodigy.net> Content-Type: multipart/alternative; boundary="------------3DCE92B4E57F8FF9B6A71D2A" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 10:04:16 -0000 This is a multi-part message in MIME format. --------------3DCE92B4E57F8FF9B6A71D2A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tony, > > Dennis, not all the way correct > > * It is also possible to get rid of IDs and passwords using FIDO. > FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS > > Depends on if you only consider “private information” PII, there can > be all sorts of information passed in ClientData field of the FIDO > response, not desirable but perfectly OK > > * None of these two semantics fit with the FIDO use case where the > subject value is scoped to be locally unique in the context of one > RS. > Hence, the linkage of users between two RSs (or between one RS and > any other server) becomes impossible > > There is nothing that prohibits the RS from sharing registration > information between RS > I am speaking of FIDO U2F where there are two main phases: registration and authentication. The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step. Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device. There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts. Denis > *From:* TXAuth *On Behalf Of *Denis > *Sent:* Thursday, August 13, 2020 10:31 AM > *To:* txauth@ietf.org > *Subject:* [GNAP] Support of FIDO > > This topic has already been tackled on the list, but I open a new > thread for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and passwords. > Since the solution in OAuth 2.0 was to use access tokens, > there have been used everywhere, even when they were not strictly needed. > > It is also possible to get rid of IDs and passwords using FIDO. FIDO > discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS. > > FIDO should be one allowed possibility for the user authentication. In > the case of FIDO, the user is authenticated under a pseudonym > specific to the RS. It may observed that there is no equivalent in > OAuth because of the two different semantics of the subject claim. > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is the > subject of the JWT.  The claims in a JWT are normally statements > about the subject. > The subject value MUST either be scoped to be locally unique in > the context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two users > between two RSs (i.e. using a locally unique identifier in the context > of the issuer) > while in the other case (i.e. using a globally unique identifier) it > is possible, in addition, to link the subject claim between one RS and > any other server > (i.e. not supporting OAuth) that is using the same globally unique > identifier. > > None of these two semantics fit with the FIDO use case where the > subject value is scoped to be locally unique in the context of one RS. > > Hence, the linkage of users between two RSs (or between one RS and any > other server) becomes impossible. > > There are cases where a user would like to enjoy the unlinkeability > properties of FIDO which cannot be met using the claims currently > defined in OAuth. > > Denis > --------------3DCE92B4E57F8FF9B6A71D2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Tony,

Dennis, not all the way correct

 

  • It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
    and no trust relationships need to be defined since there is no AS

Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

 

  • None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
    Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible

 

There is nothing that prohibits the RS from sharing registration information between RS

I am speaking of FIDO U2F where there are two main phases: registration and authentication.

The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back
to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

Denis

 

From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
Sent: Thursday, August 13, 2020 10:31 AM
To: txauth@ietf.org
Subject: [GNAP] Support of FIDO

 

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
and no trust relationships need to be defined since there is no AS.

FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.

RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.

None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis


--------------3DCE92B4E57F8FF9B6A71D2A-- From nobody Fri Aug 14 03:05:50 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 8F5883A0E8A for ; Fri, 14 Aug 2020 03:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pB20EvOTZpkz for ; Fri, 14 Aug 2020 03:05:46 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE17D3A0E7E for ; Fri, 14 Aug 2020 03:05:45 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d41 with ME id FN5j2300N2bcEcA03N5kQ1; Fri, 14 Aug 2020 12:05:44 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 12:05:44 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: From: Denis Message-ID: <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr> Date: Fri, 14 Aug 2020 12:05:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------70A157F6B8A02C5BA118DBE1" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 10:05:49 -0000 This is a multi-part message in MIME format. --------------70A157F6B8A02C5BA118DBE1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > OAuth 2.0 goal was not to get rid of usernames and passwords. It was > to stop site A from asking for the user's username and password at > site B so that site A could access resources at site B. > > How the AS authenticates the User is out of scope, and I think should > be out of scope. Maybe, may be not. Some means of authentication between a User and an AS could be recommended and documented. However, how the RS authenticates the User should be within the scope. > There are a plethora of authentication mechanisms, and standardizing > how the user authenticates is not required for interop. > Sharing the "quality" of the authentication is an area of > standardization that has been done in OpenID Connect, and I think > should be included in GNAP. > > Having said that, the Client could optionally use FIDO to authenticate > the User and somehow transmit that to the AS. No. The RS Client could optionally use FIDO to authenticate the User. Since FIDO does not mandate any AS, there is no interaction with any AS at that stage. Denis > ᐧ > > On Thu, Aug 13, 2020 at 10:31 AM Denis > wrote: > > This topic has already been tackled on the list, but I open a new > thread for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and > passwords. Since the solution in OAuth 2.0 was to use access tokens, > there have been used everywhere, even when they were not strictly > needed. > > It is also possible to get rid of IDs and passwords using FIDO. > FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS. > > FIDO should be one allowed possibility for the user > authentication. In the case of FIDO, the user is authenticated > under a pseudonym > specific to the RS. It may observed that there is no equivalent in > OAuth because of the two different semantics of the subject claim. > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is the > subject of the JWT.The claims in a JWT are normally statements > about the subject. > The subject value MUST either be scoped to be locally unique > in the context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two users > between two RSs (i.e. using a locally unique identifier in the > context of the issuer) > while in the other case (i.e. using a globally unique identifier) > it is possible, in addition, to link the subject claim between one > RS and any other server > (i.e. not supporting OAuth) that is using the same globally unique > identifier. > > None of these two semantics fit with the FIDO use case where the > subject value is scoped to be locally unique in the context of one > RS. > Hence, the linkage of users between two RSs (or between one RS and > any other server) becomes impossible. > > There are cases where a user would like to enjoy the > unlinkeability properties of FIDO which cannot be met using the > claims currently defined in OAuth. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------70A157F6B8A02C5BA118DBE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Dick,

OAuth 2.0 goal was not to get rid of usernames and passwords. It was to stop site A from asking for the user's username and password at site B so that site A could access resources at site B.

How the AS authenticates the User is out of scope, and I think should be out of scope.

Maybe, may be not. Some means of authentication between a User and an AS could be recommended and documented.

However, how the RS authenticates the User should be within the scope.

There are a plethora of authentication mechanisms, and standardizing how the user authenticates is not required for interop.
Sharing the "quality" of the authentication is an area of standardization that has been done in OpenID Connect, and I think should be included in GNAP.

Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.

No. The RS Client could optionally use FIDO to authenticate the User. Since FIDO does not mandate any AS, there is no interaction with any AS at that stage.

Denis

ᐧ

On Thu, Aug 13, 2020 at 10:31 AM Denis <denis.ietf@free.fr> wrote:

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
and no trust relationships need to be defined since there is no AS.

FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.

RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.

None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible. 

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis

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


--------------70A157F6B8A02C5BA118DBE1-- From nobody Fri Aug 14 03:12:25 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 E24CA3A0B33 for ; Fri, 14 Aug 2020 03:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no 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 ZYg84npHQZFa for ; Fri, 14 Aug 2020 03:12:22 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4112C3A0B32 for ; Fri, 14 Aug 2020 03:12:21 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d41 with ME id FNCK2300A2bcEcA03NCKsV; Fri, 14 Aug 2020 12:12:19 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 12:12:19 +0200 X-ME-IP: 90.79.51.120 To: Justin Richer Cc: Dick Hardt , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> From: Denis Message-ID: <5fb64cec-9ef3-8652-6bc6-96800a8d3665@free.fr> Date: Fri, 14 Aug 2020 12:12:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CAC5552340D394B682A0C3B3" Content-Language: en-GB Archived-At: Subject: [GNAP] User consent 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: Fri, 14 Aug 2020 10:12:24 -0000 This is a multi-part message in MIME format. --------------CAC5552340D394B682A0C3B3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)" Justin, > So what I’m saying is that what you’re defining as part of the RS was > (in Oauth) defined as a function of the AS. > As such, I contend that it needs to be its own separate functional > role, neither AS nor RS. I don't see that as separate roles, but as two different kinds of interactions with the same entity. > That way it could be fulfilled by an entity either closely tied to the > AS or closely tied to the RS, as appropriate. > It would give us more flexibility to talk about the patterns. Nevertheless, such a possibility should be explored in more depth. In my response to Dick I wrote: A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know the end result of these choices when/if it gets back one or more access tokens. Human to software interactions should be part of the protocol. RS to Client: a set of choices Client to RS: Done (choices have been done by the user). For a RS, before performing a given operation, the RS should specify to the User how many access tokens would be required, from which ASs they could be obtained and which types of attributes these access tokens should contain. For an AS, a key question would be whether some choices would be presented by the AS to the Client in a standardized way ? I don't know. What would be such choices ?  I let Dick, yourself or someone else respond but I wonder that such choices could be presented by an AS to a User (through the Client) in a standardized way. Denis >  — Justin > >> On Aug 13, 2020, at 1:29 PM, Denis > > wrote: >> >>  Justin, >> >> Your response does not address my point. I am talking of two >> different channels with the RS, i.e. not with the AS. >> >> Denis >> >>> Denis, I want to focus on one point here: >>> >>>> In OAuth 2.0, the user consent is performed by the AS using an >>>> authorize endpoint where the user consent is solicited and captured. >>>> >>>> Since a user, with no prior experience, shall first connect to a RS >>>> to perform an operation, the user consent shall be performed by the >>>> RS, >>>> instead of the AS. This means that we should define a "consent" >>>> endpoint at the RS. >>> >>> One of my goals with XYZ’s design was to be able to separate the >>> interaction with the user from the web-based flows for the >>> delegation protocol, and that aspect is enshrined in the GNAP >>> charter as well. >>> >>> It points to the reality that there are two different aspects of the >>> traditional AS that we might need to talk about separately now. One >>> deals with delegation, issuing tokens, returning data directly to >>> the client (not through a separate API, since that’s the RS), and >>> other back-channel stuff. The other aspect deals with interacting >>> with the user and/or resource owner. >>> >>> We already saw bits of this in OAuth 2: the AS is defined by the >>> pair of the token endpoint and authorization endpoint, each filling >>> the respective roles above. What if we formally separate these? >>> Strawman names: >>> >>> Delegation Server (DS) - handles the back-channel stuff >>> >>> Interaction Server (IS) - handles the front-channel stuff >>> >>> >>>  — Justin >>> >> > --------------CAC5552340D394B682A0C3B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"

Justin,

So what I’m saying is that what you’re defining as part of the RS was (in Oauth) defined as a function of the AS.
As such, I contend that it needs to be its own separate functional role, neither AS nor RS.

I don't see that as separate roles, but as two different kinds of interactions with the same entity.

That way it could be fulfilled by an entity either closely tied to the AS or closely tied to the RS, as appropriate.
It would give us more flexibility to talk about the patterns.

Nevertheless, such a possibility should be explored in more depth.

In my response to Dick I wrote:

A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices
Client to RS: Done (choices have been done by the user).

For a RS, before performing a given operation, the RS should specify to the User how many access tokens would be required, from which ASs
they could be obtained and which types of attributes these access tokens should contain.

For an AS, a key question would be whether some choices would be presented by the AS to the Client in a standardized way ? I don't know.
What would be such choices ?  I let Dick, yourself or someone else respond but I wonder that such choices could be presented by an AS
to a User (through the Client) in a standardized way.

Denis


 — Justin

On Aug 13, 2020, at 1:29 PM, Denis <denis.ietf@free.fr> wrote:

 Justin,

Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

Denis

Denis, I want to focus on one point here:

In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint at the RS.

One of my goals with XYZ’s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that’s the RS), and other back-channel stuff. The other aspect deals with interacting with the user and/or resource owner. 

We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

Delegation Server (DS) - handles the back-channel stuff

Interaction Server (IS) - handles the front-channel stuff


 — Justin




--------------CAC5552340D394B682A0C3B3-- From nobody Fri Aug 14 03:14:13 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 4989E3A0E90 for ; Fri, 14 Aug 2020 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 rnAW6y730Pz4 for ; Fri, 14 Aug 2020 03:14:08 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC34D3A0F20 for ; Fri, 14 Aug 2020 03:14:06 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d41 with ME id FNE4230052bcEcA03NE510; Fri, 14 Aug 2020 12:14:05 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 12:14:05 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> From: Denis Message-ID: <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> Date: Fri, 14 Aug 2020 12:14:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C066AB15E3E5BE2979260D09" Content-Language: en-GB Archived-At: Subject: [GNAP] User consent 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: Fri, 14 Aug 2020 10:14:12 -0000 This is a multi-part message in MIME format. --------------C066AB15E3E5BE2979260D09 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)" Hi Dick, > I don't see how we can technically standardize a user experience, and > it is not clear why a standard would be needed for interoperability. I already wrote a proposal and made it available to the mailing list. An access will be granted by a RS based on an mathematical expression which is formed using some combination of ANDand OR conditions. Examples of combinations: /condition 1/AND/condition 2 condition 1/OR /condition 2/ (/condition 1/AND/condition 2)/OR/condition 3 (condition 1/OR /condition 2)/AND/condition 3/ The following notation is being used for the /conditions/: /condition x/= { AS identifier + set of attributes types } Each RS internally constructs an /authorization table/ with the following content: 1°For the "authentication" operation: either FIDO U2For a mathematical expression using conditions; 2°For any other operation: a mathematical expression using conditions. Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions used in that mathematical expression. The User may then decide whether they are appropriate to him or not. >  In many jurisdictions there are regulations regarding what > information needs to be conveyed to a user, and potentially a consent > requirement, > for example a site explaining its use of cookies -- but I don't see > how IETF would play a role in that. > > On a related note, the browsers attempted to standardize the username > / password prompt, and that has been rejected by pretty much every site. > The only site I've visited in the last decade that has used the > browsers' built in username / password prompt was the W3C site -- and > it was a frustrating > experience since there was no button for account recovery -- it would > just keep popping up. What I am proposing is unrelated to the two above cases you mention. Denis > > > ᐧ > > On Thu, Aug 13, 2020 at 10:29 AM Denis > wrote: > > Dick, > >> I think Tom's objection, and I agree with it, is that humans >> don't interact in bits and bytes. >> >> I think it is useful to separate human interactions with software >> from software interactions with software. >> The latter we can standardize, the former we can call out as part >> of the overall process, but it is not something >> that is testable or required for interop, so I would argue human >> to software interactions are NOT part of the protocol. > > I disagree.  A set of a choices should be presented by the RS to > the Client in a standardized way. The choices made by the user > should be locally recorded by the Client, hence the RS does not > need to be informed of these choices. The RS will only know > the end result of these choices when/if it gets back one or more > access tokens. > > Human to software interactions should be part of the protocol. > > RS to Client: a set of choices > > Client to RS: Done (choices have been done by the user). > > Denis > > >> >> ᐧ >> >> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer > > wrote: >> >> It’s a role fulfilled by a person, so I’m not sure where the >> objection you’re raising comes from. >> >> Also, whatever roles we define here, whether software or >> human-ware, they need to be related to the protocol. >> >>  — Justin >> >>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>> >> > wrote: >>> >>> I strong object to the objectification of human users. It is >>> way past time that the IETF becaume user oriented instead of >>> web service oriented. >>> users are human in my language. >>> Peace ..tom >>> >>> >>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer >>> > wrote: >>> >>> If defined as the party operating the client software, >>> then the user is a role. I believe this is more accurate >>> and inclusive than the definition you have proposed with >>> the user as an entity. >>> >>>  - Justin >>> ________________________________________ >>> From: Dick Hardt [dick.hardt@gmail.com >>> ] >>> Sent: Tuesday, August 11, 2020 6:21 PM >>> To: Francis Pouatcha >>> Cc: Justin Richer; Denis; Benjamin James Kaduk; >>> txauth@ietf.org >>> Subject: Re: [GNAP] [Txauth] Revisiting the photo >>> sharing example (a driving use case for the creation of >>> OAuth) >>> >>> Hi Francis >>> >>> The user is an entity, not a role in the protocol in how >>> I am defining roles, so steps (1) and (7) are confusing >>> to me on what is happening. >>> >>> I also think that (2) could be an extension to GNAP, >>> rather than part of the core protocol. >>> >>> >>> >>> >>> >>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>> >> >> >> wrote: >>> In this context, I suggest we pick some words to work >>> with, and sharpen them as we move on, discover and map >>> new use cases to the protocol. >>> >>> In this diagram from the original thread >>> (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), >>> I replaced the words: >>> >>> +-----------+      +--------------+ +----+  +----+ >>> +---------------------+ >>> | Requestor |      | Orchestrator | |    |  | GS |  | >>> Resource Controller | >>> |   was     |      |     was      | | RS |  | or |  |    >>>      was  | >>> |  User     |      |   Client     | |    |  | AS |  |    >>> Resource Owner  | >>> +-----------+      +--------------+ +----+  +----+ >>> +---------------------+ >>>   |(1) ServiceRequest     |   |       |                | >>>   |---------------------->|       |       |                | >>>   |                       |(2) >>> ServiceIntent:AuthZChallenge     | >>>   |  |<---------->|       |         | >>>   |                       |   |       |                | >>>   |                       |(3) >>> AuthZRequest(AuthZChallenge)     | >>>   |  |------------------->|       | >>>   |                       |   |       |(4) >>> ConsentRequest:Grant >>>   |                       |   |       |<-------------->| >>>   |                       |(5) GrantAccess(AuthZ)        >>>        | >>>   |  |<-------------------|       | >>>   |                       |   |       |                | >>>   |                       |(6) >>> ServiceRequest(AuthZ):ServiceResponse >>>   |  |<---------->|       |         | >>>   |(7) ServiceResponse    |   |       |                | >>>   |<----------------------|       |       |                | >>>   +                       +   +       +                + >>> >>> The purpose of the GNAP protocol is to help negotiate >>> access to a protected resource. It starts with a >>> requestor delegating activity to an orchestrator. These >>> are all roles, no entities. Let focus on mapping the use >>> cases to the protocol roles and interactions so wwe can >>> discover what is missing. >>> >>> It seems cumbersome to use it in discussions as it is >>> impossible to give the word "Client" a clear definition. >>> >>> We can mention in the final document, that the >>> "Orchestrator" (or whatever word we finally use) plays >>> the same role as the "Client" in oAuth2. >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> >>> >>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>> >> >> >> wrote: >>> I agree with Justin. Redefining well used terms will >>> lead to significant confusion. If we have a different >>> role than what we have had in the past, then that role >>> should have a name not being used already in OAuth or OIDC. >>> >>> Given what we have learned, and my own experience >>> explaining what a Client is, and is not, improving the >>> definition for Client could prove useful. I am not >>> suggesting the term be redefined, but clarified. >>> >>> For example, clarifying that a Client is a role an >>> entity plays in the protocol, and that the same entity >>> may play other roles at other times, or some other >>> language to help differentiate between "role" and "entity". >>> >>> /Dick >>> [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ >>> >>> >>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>> >> >> >> wrote: >>> I’m in favor of coming up with a new term that’s a >>> better fit, but I’m not really in favor of taking an >>> existing term and applying a completely new definition >>> to it. In other words, I would sooner stop using >>> “client” and come up with a new, more specific and >>> accurate term for the role than to define “client” as >>> meaning something completely different. We did this in >>> going from OAuth 1 to OAuth 2 already, moving from the >>> even-more-confusing “consumer” to “client”, but OAuth 2 >>> doesn’t use the term “consumer” at all, nor does it use >>> “server” on its own but instead always qualifies it with >>> “Authorization Server” and “Resource Server”. >>> >>> GNAP can do something similar, in my opinion. But what >>> we can’t do is ignore the fact that GNAP is going to be >>> coming up in a world that is already permeated  by OAuth >>> 2 and its terminology. We don’t have a blank slate to >>> work with, but neither are we bound to use the same >>> terms and constructs as before. It’s going to be a >>> delicate balance! >>> >>>  — Justin >>> >>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>> >> >> >> wrote: >>> >>> I think that is fundamentally part of the question: >>> We are clear that we are producing a protocol that is >>> conceptually (if not more strongly) related to OAuth >>> 2.0, and reusing terms >>> from OAuth 2.0 but with different definitions may lead >>> to unnecessary >>> confusion >>> >>> If we say that this document assumes OAuth2.0 >>> terminology, then we should not change the meanings of >>> any definition. If we are saying this supersedes or >>> replaces what OAuth 2.0 creates, then we should pick the >>> best word for the job and ignore conflicting meanings >>> from OAuth 2.0. I have a lot of first hand experience of >>> industries "ruining words", and attempting to side-step >>> the problem rather than redefining the word just >>> confuses everyone as everyone forgets the original >>> meaning as new documents come out, but the confusion >>> with the use of a non-obvious word continues. >>> >>> Food for thought. >>> - Warren >>> >>> [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA] >>> >>> Warren Parad >>> Founder, CTO >>> >>> Secure your user data and complete your authorization >>> architecture. Implement Authress>> .ly/37SSO1p>. >>> >>> >>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>> >> >> >> wrote: >>> Hi Denis, >>> >>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>> > Hi Justin, >>> > >>> > Since you replied in parallel, I will make a response >>> similar to the one >>> > I sent to Dick. >>> > >>> > > Hi Denis, >>> > > >>> > > I think there’s still a problem with the terminology >>> in use here. What >>> > > you describe as RS2, which might in fact be an RS >>> unto itself, is a >>> > > “Client” in OAuth parlance because it is /a client >>> of RS1/. What you >>> > > call a “client” has no analogue in the OAuth world, >>> but it is not at >>> > > all the same as an OAuth client. I appreciate your >>> mapping of the >>> > > entities below, but it makes it difficult to hold a >>> discussion if we >>> > > aren’t using the same terms. >>> > > >>> > > The good news is that this isn’t OAuth, and as a new >>> WG we can define >>> > > our own terms. The bad news is that this is really >>> hard to do. >>> > > >>> > > In GNAP, we shouldn’t just re-use existing terms >>> with new definitions, >>> > > but we’ve got a chance to be more precise with how >>> we define things. >>> > >>> > In the ISO context, each document must define its own >>> terminology. The >>> > boiler plate for RFCs does not mandate a terminology >>> or definitions section >>> > but does not prevent it either. The vocabulary is >>> limited and as long as >>> > we clearly define what our terms are meaning, we can >>> re-use a term already >>> > used in another RFC. This is also the ISO approach. >>> >>> Just because we can do something does not necessarily >>> mean that it is a >>> good idea to do so.  We are clear that we are producing >>> a protocol that is >>> conceptually (if not more strongly) related to OAuth >>> 2.0, and reusing terms >>> from OAuth 2.0 but with different definitions may lead >>> to unnecessary >>> confusion.  If I understand correctly, a similar >>> reasoning prompted Dick to >>> use the term "GS" in XAuth, picking a name that was not >>> already used in >>> OAuth 2.0. >>> >>> -Ben >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> >> > >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> >> > >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> >> > >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> 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/ >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------C066AB15E3E5BE2979260D09 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"

Hi Dick,

I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted by a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

Examples of combinations:

condition 1 AND condition 2
condition 1 OR condition 2
(condition 1 AND condition 2) OR condition 3
(condition 1 OR condition 2) AND condition 3

The following notation is being used for the conditions:

condition x = { AS identifier + set of attributes types }

Each RS internally constructs an authorization table with the following content:

1°  For the "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

2°  For any other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

 In many jurisdictions there are regulations regarding what information needs to be conveyed to a user, and potentially a consent requirement,
for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that. 

On a related note, the browsers attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis



ᐧ

On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
Dick,

I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes. 

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.  A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



ᐧ

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It’s a role fulfilled by a person, so I’m not sure where the objection you’re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

 — Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

 - Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto: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/
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


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


--------------C066AB15E3E5BE2979260D09-- From nobody Fri Aug 14 05:23:30 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 07DD63A1078 for ; Fri, 14 Aug 2020 05:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 6NJYBBQbHS8M for ; Fri, 14 Aug 2020 05:23:26 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 4833C3A1075 for ; Fri, 14 Aug 2020 05:23:26 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id p18so4416025ilm.7 for ; Fri, 14 Aug 2020 05:23:26 -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=PzTDQ7vlwJNkDoGmSCYJtvxWCfzLKvkgsPbXscae5rM=; b=JJtHn2Uuf1GtagjG6AuQbsYINQy/WyrJbqCbFchRE3sq3Z1gRvwMvFKrB2IiMAM2me PyYJs6RyH5Ov10x9Am2Wg26VRLBCmticlWlZ8zOGYSGMMbkbQNLf+EuYSY8qoCagzwNB MBPohIDAgxiO6DlR7KXTzT30vEJhc2+KYF1XabGkaCi5XikR91lF3a2hEOYInqkkFmPw Ba6Y1RHgop9CPEZ8dD4iLyEAp/JOO/xwEW+DNTJiFe5SLQmk8dLb2LCM8ICmavd8+iUK UiuSP+cKAhOtFM9oAcLeyZAtJytddEMuRGtyUG9E76isRRPP6irRGYVrCpcsbrXbuY4J PxQw== 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=PzTDQ7vlwJNkDoGmSCYJtvxWCfzLKvkgsPbXscae5rM=; b=RpOxCoruT/8V0tfdmT6bFRqlTXTI1EbJ9yThwi+1IOmu8+NSjO4mPth1aK5lCAykBD +7z3lgLirWlT2zwmJKgs1JWaA0ZZ3jEtx1PL84Yx97yWdPpIbIJMZBRKEG+i7wx2tl50 m19bhv69WlOn1bmcumr6spT4+sfLH+Dhnb79/cEq7aGmBu+ltaYjrmxnvKdzxxRvo2vy A7TIsnOqA8zDPzwGj2uZR3Q6kIKHg0vukw4THfjLyon20sbWpiY2dNWLkCJrj7xcLmGq AXoueBz4jyLu2FohDWIBaYnvOmws0TI0O6CVFCmDbOiTB3l1ppZ2N0Q7sNPKttMMGPwb a/nA== X-Gm-Message-State: AOAM533hN3ChNG5G1v2ep0HvorHCRxPlXJ30a4AZB9dACjRdemjYOQVj wnzQF1OPlyBeKr38HVR3mn91RKlLmq8u1GgJTBo= X-Google-Smtp-Source: ABdhPJw6Rm4JxUlol6/yLikoCcq2N6nX1/SkfSOqIXHYP6a+KneMIE4Y3bheC20l9vdS9icBvojlK5/SFkXlJTVydts= X-Received: by 2002:a92:480f:: with SMTP id v15mr2130241ila.123.1597407805606; Fri, 14 Aug 2020 05:23:25 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> In-Reply-To: <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> From: Fabien Imbault Date: Fri, 14 Aug 2020 14:23:14 +0200 Message-ID: To: Denis Cc: Dave Tonge , Francis Pouatcha , Justin Richer , Mike Jones , Benjamin Kaduk , Tom Jones , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000d0901c05acd57c1f" Archived-At: Subject: Re: [GNAP] Terminology 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: Fri, 14 Aug 2020 12:23:29 -0000 --000000000000d0901c05acd57c1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, Thanks for your feedback. Comments inline (marked with FI). Fabien On Fri, Aug 14, 2020 at 12:02 PM Denis wrote: > Hi Fabien, > > Thank you for your inputs, a ball is finally rolling. > > An attempt. > > I would add upfront: User =3D human person > > FI : then end-user is clearer if you want to indicate specifically a huma= n user. One can also create system users. > * =3D application that requests access to Resource Servers (RS) > through a Grant Server (GS). * > Examples: a web server, a browser-based app, a mobile app, an IoT device. > > A few explanations: "through" does not sound appropriate since it could b= e > interpreted as the GS being necessarilly placed between the Client and th= e > RS. > In addition, more than one GS may b= e > necessary. > > My proposal: * =3D application that requests access to Resource > Servers (RS) **on behalf of a User by using one or more Grant Servers > (GS) * > *Examples: a web server, a browser-based app, a mobile app.* > > FI: agreed. > *GS =3D computing service that manages the grant lifecycle to a = on > behalf of a Resource Controler (RC).* > Note : for privacy reasons, the GS may be issuing grants without knowledg= e > of which resources are requested. > > I dislike "*on behalf of a Resource Controler (RC)*". The GS may be fully > ignorant of the existence of the RSs and hence of the RCs. > In addition, "*grant life cycle*" is undefined. > > My proposal: *GS =3D server issuing access tokens to a Client after > successfully authenticating the User* > > > *Note 1: for privacy reasons, the GS may be issuing access tokens without > the knowledge of which resources are requested. Note 2: a GS is able to > disclose to a User the User attributes that it manages. * > > FI: I find the new definition less clear. It's not because you don't know which RS is called that we shouldn't say the decision is made by the RC. "grant life cycle" is indeed currently undefined, what i had in mind is basically the grant flow from the GNAP protocol, possibly also including revocation etc. Not sure why Note 2 is important to put here. > *RS =3D computing service that grants access only if its Resource Control= er > (RC) consents.* > Note : the consent may involve a human interaction or may be automated > based on access control policies. > > I dislike "*its Resource Controler (RC) consents" *because it may let > think that a human person always needs to consent. > > My proposal: *R* > *S =3D server hosting protected resources, capable of accepting and > responding to protected resource requests > when access tokens are being used* > > FI : that is why I suggested a note to make sure it is correctly understood. I'm not sure the proposed alternative is clearer. > > *RC =3D entity which is controlling the access to a protected resource. * > Note : a RC may be manually operated by a human or delegated to a machine= , > partially or completely. > > A RC is not an entity but a function. I would also place the machine case > first. > > My proposal: > *RC =3D function tightly coupled with a RS which controls the accesses to= a > protected resource * Note : the function may be > operated either by a machine or by a human person or by some combination = of > both. > > FI : your proposition on the note makes it much better. On the main definition, I'm not sure what you mean by function, as a result I'm not sure a reader would understand. Why do you need to say "tightly coupled?" > *Consent =3D the process of asking a RC to accept or decline based on a > grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D o= r =E2=80=9Cno=E2=80=9D consent > decision.* > > I would instead speak of the "User Consent". The User Consent is a set of > choices among a proposed set of choices. It is not simply a "yes" or "no" > consent decision. > > My proposal: *User Consent =3D ability for a User, after being informed, = of > choosing to release or not to a RS some attributes contained in one or mo= re > access tokens* > > FI: this may be misleading I think. The consent is done by a RC (or in OAuth terms, RO), not the application user. I agree there may be a combination of consent decisions, but I think it's important to say that in the end for each individual choice, you do have a yes/no decision. > > Denis > > > Fabien > > On Thu, Aug 13, 2020 at 3:55 PM Denis wrote: > >> Fabien, >> >> IMHO, nothing is wrong with keeping "Client" since it has a wide spread >> usage >> ... but only as long as we can agree on a short and a clear definition >> for it. >> >> I can provide the beginning of such a definition: " application ..." >> >> If someone could go a little bit further, this would help. :-) >> >> A similar argumentation for GS. It could be used but only as long as we >> can agree on a short and a clear definition for it. >> Any proposal ? >> >> Denis >> >> Hi, >> >> Nothing inherently wrong with Client/AS, which has worked for years in >> the context of OAuth2. The question is to know whether we can build the = new >> protocol with the same concepts and deal with their known limitations, o= r >> if we're better off with more adapted concepts less prone to >> misunderstandings. >> >> Verb vs Noun: >> Problem is that the grant (noun) can only be understood if there is a >> grant(verb), i.e. some action that grants something. >> The grant (noun) definition directly derives from the verb : "something >> granted ..." >> >> I personally have no issue even with the fairly convoluted "The Grant >> Server issues a grant to the Grant Client representing access that has b= een >> granted" (except perhaps from the word Client, but that's a different >> issue). >> By the way, grant is nothing new, it's used extensively in OAuth2 as >> "grant types" (whatever that means). >> >> Dick summarized well the reasons why he uses GS instead of AS : >> 1) "grant" is in the working group name (a weaker reason, but still has >> been approved). Question: would our reasoning if the protocol ended up >> being called OAuth3? >> 2) grant =3D larger in scope than AS (not only authorization), as it at >> least includes idclaims + other use cases like payment (?) - no consensu= s, >> see difference in appreciation between Justin and Dick >> >> As for "Client", if most people think it is problematic, it seems a good >> reason to change if we find a better alternative. >> Quoting Dick again: "The confusion in my experience usually stems from >> people working with software that is acting in multiple roles. IE, the >> software that is acting as a client in once context, is also acting as >> an RS in other contexts, or even acting as an AS. The other confusion is >> that people view clients as being the software the user is using -- >> although it may not be acting as a client in the oauth context." and >> later "I do agree that it is not the best term in GNAP. Primarily becaus= e >> GNAP is a combination of the client from OAuth 2, and the relying party >> from OIDC." >> >> So far there's no consensus however, recent tries: Initiating Applicatio= n >> (Denis), Orchestrator (Francis). >> >> Cheers >> Fabien >> >> >> >> >> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >> wrote: >> >>> I would be against using "grant" as both a verb and a noun and stick >>> purely with one or the other. (In the charter the only use of "grant" i= s in >>> the verb: "granted"). >>> >>> Using it as both a verb and a noun will be confusing and less accessibl= e. >>> >>> I think it will be confusing to say "The Grant Server issues a grant to >>> the Grant Client representing access that has been granted" >>> >>> Whether the access takes place via a token being returned and used at a >>> resource server, or "claims" that are directly returned from the "Grant >>> Server" I think should be largely irrelevant when it comes to the namin= g of >>> the roles. >>> >>> In almost all use cases that I have seen the "Grant Server" is making a >>> policy based decision "to grant" access to requested resource(s). To me= , >>> that is the fundamental operation happening. I think nearly all use cas= es >>> can be applied to that, e.g. the GS grants access to >>> - identity attributes for the end user >>> - verify an identity attribute (e.g. that user is over 18) >>> - all users photos at resource server X >>> - a single photo with id 12345 at resource server Y >>> - resource of type X at any resource server that trusts the Grant Serv= er >>> - call a payment API with specific properties (e.g. amount < 5) >>> - call a file storage API >>> - call a "contract signing" API with specific properties (e.g. contrac= t >>> hash of xxx,) >>> >>> While "client" is problematic, it does now have wide spread usage, so >>> perhaps we are stuck with it. >>> However I agree with Justin and think "Grant Client" makes things more >>> confusing. >>> >>> What is wrong with keeping "Client" and "Authorization Server"? >>> >>> Dave >>> >>> >>> >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS= 1 >>> 6EA. >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d0901c05acd57c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

Thanks for y= our feedback.=C2=A0
Comments inline (marked with FI).
<= br>
Fabien

On Fri, Aug 14, 2020 at 12:02 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hi Fabien,

Thank you for your inputs, a ball is finally rolling.

=20
An attempt.
I would add upfront: User =3D=C2=A0 human person
FI : then end-user is clearer if you want to indi= cate specifically a human user. One can also create system users.
<Client> =3D application that requests access to Resource Servers (RS) through a Grant Server (GS).=C2=A0= =C2=A0
Examples: a=C2=A0web server, a browser-based app, a mobile app, an IoT device.

A few explanations: "through" does not sound appropriate= since it could be interpreted as the GS being necessarilly placed between the Client and the RS.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition, more than one GS may be necessary.

My proposal:=C2=A0 <Client> =3D application that requests access to Resource Servers (RS) on behalf of a=C2=A0Use= r by using one or more Grant Servers (GS)
Examples: a=C2=A0web server, a browser-based app, a mobile app.<= /i>

FI: agreed.=C2=A0=C2=A0

GS =3D computing service that manages the grant lifecycle=C2=A0to a <Client> on behalf of a Resource Controler (RC).
Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested.

I dislike "on behalf of a Resource Controler (RC)"= ;. The GS may be fully ignorant of the existence of the RSs and hence of the RCs.
In addition, "grant life cycle" is undefined.

My proposal:=C2=A0 GS =3D server issuing access tokens t= o a Client after successfully authenticating the User
Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested. Note 2: a GS is able to disclose to a User the User attributes that it manages.=C2=A0

FI: I find the new definition less clear. It's not because you d= on't know which RS is called that we shouldn't say the decision is = made by the RC.=C2=A0
"grant life cycle" is indeed curr= ently undefined, what i had in mind is basically the grant flow from the GN= AP protocol, possibly also including revocation etc.
Not sure why= Note 2 is important to put here.
=C2=A0

RS =3D computing service that grants access only if its Resource Controler (RC) consents.
Note : the consent may involve a human interaction or may be automated based on access control policies.
I dislike "its Resource Controler (RC) consents&quo= t; because it may let think that a human person always needs to consent.

My proposal: RS =3D server hosting protected resources, capable of accepting and responding to protected resource requests
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when access token= s are being used
FI : that is why I sug= gested a note to make sure it is correctly understood. I'm not sure the= proposed alternative is clearer.=C2=A0

RC =3D entity which is controlling the access to a protected resource.=C2=A0
Note : a RC may be manually operated by a human or delegated to a machine, partially or completely.

A RC is not an entity but a function. I would also place the machine case first.

My proposal: RC =3D function tightly coupled with a RS which controls the accesses to a protected resource
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Note : the function may be operated either by a machine or by a human person or by some combination of both.

FI : your proposit= ion on the note makes it much better. On the main definition, I'm not s= ure what you mean by function, as a result I'm not sure a reader would = understand. Why do you need to say "tightly coupled?"=C2=A0
=
Consent =3D the process of asking a RC to accept or decline based on a grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D or =E2=80=9Cno=E2=80=9D con= sent decision.

I would instead speak of the "User Consent". The User Co= nsent is a set of choices among a proposed set of choices. It is not simply a "yes" or "no" consent decision.

My proposal: User Consent =3D ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens


FI: this may be misleading I th= ink. The consent is done by a RC (or in OAuth terms, RO), not the applicati= on user.=C2=A0
I agree there may be a combination of consent deci= sions, but I think it's important to say that in the end for each indiv= idual choice, you do have a yes/no decision.=C2=A0


Denis


Fabien

On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr> wrote:
Fabien,

IMHO, nothing is wrong with keeping "Client" since it has a wide spread usa= ge
... but only as long as we can agree on a short and a clear definition for it.
I can provide the beginning of such a definition: " application ..."

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.=C2= =A0 It could be used but only as long as we can agree on a short and a clear definition for it.
Any proposal ?=

Denis

Hi,

Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings.

Verb vs Noun:
Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something.=C2=A0
The grant (noun) definition directly derives from the verb : "something granted ..."

I personally=C2=A0have no issue even with the fairly convoluted "The Grant Server issues a grant = to the Grant Client representing access that has been granted" (except perhaps from the word Client, b= ut that's a different issue).
By the way, grant is nothing new, it's use= d extensively in OAuth2 as "grant types" (wha= tever that means).=C2=A0

Dick summarized well the reasons why he uses GS instead of AS :=C2=A0
1) "gra= nt" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
2) grant =3D larger in scope than AS (not only authorization), as it at least includes idclaims=C2=A0+ other use cas= es like payment (?) - no consensus, see difference in appreciation between Justin and Dick

As for "Client", if most people think it is proble= matic, it seems a good reason to change if we find a better alternative.=C2=A0
Quoting Dick again: "The confusion in my experien= ce usually stems from people working=C2=A0with software=C2= =A0that is acting in multiple=C2=A0roles. IE, the software=C2= =A0that is acting as a=C2=A0client=C2=A0in once co= ntext, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view=C2=A0clients=C2=A0as being the softwa= re the user is using -- although it may not be acting as a=C2= =A0client=C2=A0in the oauth context." and later "I do agree tha= t it is not the best term in GNAP. Primarily because GNAP is a combination of the=C2=A0client=C2=A0from= OAuth 2, and the relying party from OIDC."

So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis).=C2=A0

Cheers
Fabien




On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I would be against using "grant" as both a verb and a no= un and stick purely with one or the other. (In the charter the only use of "grant" is in= the verb: "granted").

Using it as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted"

Whether the access takes place via a token being returned and used at a resource server, or "claims" that are dir= ectly returned from the "Grant Server" I think = should be largely irrelevant when it comes to the naming of the roles.

In almost all use cases that I have seen the "Grant Server" is ma= king a policy based decision "to grant" access t= o requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
=C2=A0- identity=C2=A0attributes for the end user
=C2=A0- verify=C2=A0an identity attribute (e.g. that user is over 18)
=C2=A0- all users photos at resource server X
=C2=A0- a single photo with id 12345 at resource server Y
=C2=A0- resource of type X at any resource server that trusts the Grant Server
=C2=A0- call a payment API with specific properties (e.g. amount < 5)
=C2=A0- call a file storage API
=C2=A0- call a "contract signing" API with specific properties (e.g. contract hash of xxx,)
=C2=A0
While "client" is problematic, it does now have wide spread usage, so perhaps we are stuck with it.=C2=A0
However I agree with Justin and think "Grant Client" makes things mor= e confusing.

What is wrong with keeping "Client" and "Authorization Server&q= uot;?=C2=A0

Dave




Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is e= ntered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temp= le Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

= DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.




--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d0901c05acd57c1f-- From nobody Fri Aug 14 06:05:04 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 054383A10B3 for ; Fri, 14 Aug 2020 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=securekeytechnologies.onmicrosoft.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 iJhQR7D4a93T for ; Fri, 14 Aug 2020 06:05:00 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670107.outbound.protection.outlook.com [40.107.67.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEBC3A10B1 for ; Fri, 14 Aug 2020 06:05:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gFh52Eq3jB7ysgmUxCbrI2Sq19Cup9ZrUeY7rByYJy/icQKxkjOrZB3foyXlDqu88TLsp660jE4oP02caOalz42/rxf7NCsj82UWYUF5fLfKB3BffmtFEl41+o5ER7rO/50nYzWFlPj1UYnCiFS+gThNkaRculTTX+t5iru9Xahoh9ltlr7kkuPV6X/p9NwRTUDd83OVikQh1oChL6IA7fry1VUD6NF45PcNujAvOCiphvDLznXScSdoxAiOVjW12NaUTYpKYaj36OZNXI7cvTMDmKfhETFtcuC8JNOmAczX+IsXMSXOTeb+sQbNBxvEGDBbRHngbQ6B72BZ8zzJvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogC7VO4JX70qBoHG+npoDFQVFsW+aDlJyn85XL179/Y=; b=fte283M6toxGcsr1WpGu45ik60RekHWu26pEZYp/wdH2gVklzCSWI1rrIpLBaaAaFdV7MVFpKBQRorpVl7S6x0jkq2rd7OZ36oK7dBenTRXJFvNlbEDaj/su+HmUSWNttkXr7dxR/v3mWN6stMJ/W+JN34UGy6RtXw9Qn+MAR/g5pFlUp/H7xUjl5lUc7dbH5RwiCs2+6CkHZ7pdwQzbAd/fSrwsa3iHoyrEYzB610v+NS1CR9XIiFXPtPODKDDMyJUbut+t1+5gxy7qdiiBqfcRyros+tzlXaC0Wl57RkS+k+gLoTKH+SjDXBsrCjdoMZoc2KeDXiPex2SdVh7OWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekeytechnologies.onmicrosoft.com; s=selector1-securekeytechnologies-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogC7VO4JX70qBoHG+npoDFQVFsW+aDlJyn85XL179/Y=; b=VrjWCAfO3ikQ5L9VglIg00zMSSCGmLdc1kR6gQmTnVkX6KF9hdKHHiaQCNzYSi3mVfcjJRfasHznmpHVsBmHMjai3FNd2EJ65HJ/PO41uizxA0XzMTpHb0t9IOc8HcRfdFyst25ozsKKeFnwwb5ynjYOnhQz0Bwa7xAP91Iboc0= Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:8::32) by YTOPR0101MB1964.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:24::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.22; Fri, 14 Aug 2020 13:04:52 +0000 Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::1cba:f8fa:84c4:a7ca]) by YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::1cba:f8fa:84c4:a7ca%7]) with mapi id 15.20.3261.025; Fri, 14 Aug 2020 13:04:52 +0000 From: Mike Varley To: Denis , Dick Hardt CC: "txauth@ietf.org" Thread-Topic: [GNAP] Support of FIDO Thread-Index: AQHWcZeY9Pi2SFii40OWoJUpH3eW6Kk2Wd8AgAEH4oD//+7+AA== Date: Fri, 14 Aug 2020 13:04:52 +0000 Message-ID: <75441F90-C6A5-4BAD-B49E-F4FCC2DE55C9@securekey.com> References: <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr> In-Reply-To: <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=securekey.com; x-originating-ip: [64.231.235.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38f15b42-ea20-4b80-9901-08d84052a254 x-ms-traffictypediagnostic: YTOPR0101MB1964: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1247; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4HK3qUD5iPOVvNDbCSicmke+w7AtTJ613gczmWeP07NNXMYl5vpZ5UdMoOA7ssID8usSqpPhpTp19QkQtDgr4HCDtky7izF6qJG8IpUoZS52/fVA1oXeDBGP2ktdBoxyUVcgzhgQz5cV3anbILxt8k4qw2v4cdFz6Nn7MUqgPgzBzJQgtllNZOm+2on38qGVKHyEzX+VdhE5lqSq2SFoQM9SdvMbSphx0wrz8523uDzD2M1NvC5+YyMml6CZdOuGDFS4WToGb5Y91jMxZcbQLJUiLExg2tHA2JaN19d5EG8YM9kwyrCjIvUJOuQ3Hwgo6WHRCi9Hqq/d21aA1SCvshGZvRMmINcDKnOo0gBCoEHqKkxXD9eYd42BxVoKlbIzlstQ/bjK9/8S8jeLKr4m2AxSyyWaOZl+4fUXoMzatncr9v91u4YFlqk5lv7vUovyy+8i29eyHUPrKuyHIFKq9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(136003)(39850400004)(366004)(8676002)(83380400001)(44832011)(2616005)(8936002)(166002)(26005)(6486002)(86362001)(186003)(478600001)(36756003)(6506007)(53546011)(5660300002)(110136005)(33656002)(316002)(2906002)(6512007)(64756008)(66446008)(66476007)(66556008)(4326008)(71200400001)(76116006)(966005)(66946007)(15866825006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xR2LVJjNsITUz09SuhcwGwpnfTld1qtbahJI15shocOsFtMqpHAN0RYPcXqEBCVJt7/soj/PmmZffkafe+RRmVPB6mTx1nmvMumITAdzWjsxIz2C4UwgYIrwfH/suqo/W6E98C219NfhvXOjkP9AZSBBtNXeseT+PTV0PkmUvsecAIYIsDv+ECTT84iwuvytskRh9IjVgkCb8bGZjJoxQYBk332fOQGzQoKfvU71p1sY/PhPurnDEZOKfpQ22OOjTYvNNoWGLBRLbS3q7keckzm8jwt+bXw0NqIWlfxgi9lDsrF1Q4fOhQSpydsARnbC9g/lJiewymmAiXinf3opiEldMWmmSullBV4cOPf0zTEOyedYzwUiL/Je+BGruIb1qlv7ntUxzQw+01zeaNgS0bd3t97JV8x2r7ETt49xrD8AKmbaX98eY40Fwu2KasTag+d7PHB0wgJudhKSRqD59NHdqW/ljCKLYap8pnDStiiUqf+Xhsy3OAOIi0boVWXz9epaa2LImT2VpgmrDZs6rj52xyKlijKX+5oNynXEAqdd+Y5fQIOLQoQoekln8IYUW1jF5asoFUMCyOYPl1PScCOc44TZv0wHIcjmwVsPCfNclrE3GkvX5JhfHPiE+8QW0sBsV2JtZk05FeaqleCFEQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_75441F90C6A54BADB49EF4FCC2DE55C9securekeycom_" MIME-Version: 1.0 X-OriginatorOrg: securekey.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 38f15b42-ea20-4b80-9901-08d84052a254 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 13:04:52.7084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /bTpNPkNwdTAsVAbLZfKnAz6VaSlGFeNfSOtp1FKtW/ja5VQI3DaPbLDF/PR/iOHHB5VGmlMHM5/uILQt1gi9EyoGEe3mqQh5yz67W7WTlk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1964 Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 13:05:03 -0000 --_000_75441F90C6A54BADB49EF4FCC2DE55C9securekeycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBhbGxvd2luZyBhIHRydXN0ZWQgQ2xpZW50IHRvIGF1dGhOIHRoZSBlbmQgdXNlciBh bmQgaGF2ZSB0aGUgQVMgdHJ1c3QgdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBhbiBpbXBvcnRhbnQg ZmVhdHVyZSwgZXNwZWNpYWxseSBmb3IgbW9iaWxlIGNsaWVudCBvciBpbiB0aGUgZXhhbXBsZSBv ZiBGSURPL1dlYkF1dGhOLg0KSSBoYXZlIGNhcHR1cmVkIHRoZSB1c2UgY2FzZSBoZXJlOg0KaHR0 cHM6Ly9naXRodWIuY29tL2lldGYtd2ctZ25hcC9nZW5lcmFsL3dpa2kvQ2xpZW50LWNhbi1BdXRo Ti1FbmQtVXNlcg0KDQpNVg0KDQpGcm9tOiBUWEF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj4NCkRhdGU6IEZyaWRheSwg QXVndXN0IDE0LCAyMDIwIGF0IDY6MDUgQU0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdt YWlsLmNvbT4NCkNjOiAidHhhdXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtHTkFQXSBTdXBwb3J0IG9mIEZJRE8NCg0KSGkgRGljaywNCg0KT0F1dGggMi4wIGdv YWwgd2FzIG5vdCB0byBnZXQgcmlkIG9mIHVzZXJuYW1lcyBhbmQgcGFzc3dvcmRzLiBJdCB3YXMg dG8gc3RvcCBzaXRlIEEgZnJvbSBhc2tpbmcgZm9yIHRoZSB1c2VyJ3MgdXNlcm5hbWUgYW5kIHBh c3N3b3JkIGF0IHNpdGUgQiBzbyB0aGF0IHNpdGUgQSBjb3VsZCBhY2Nlc3MgcmVzb3VyY2VzIGF0 IHNpdGUgQi4NCg0KSG93IHRoZSBBUyBhdXRoZW50aWNhdGVzIHRoZSBVc2VyIGlzIG91dCBvZiBz Y29wZSwgYW5kIEkgdGhpbmsgc2hvdWxkIGJlIG91dCBvZiBzY29wZS4NCg0KTWF5YmUsIG1heSBi ZSBub3QuIFNvbWUgbWVhbnMgb2YgYXV0aGVudGljYXRpb24gYmV0d2VlbiBhIFVzZXIgYW5kIGFu IEFTIGNvdWxkIGJlIHJlY29tbWVuZGVkIGFuZCBkb2N1bWVudGVkLg0KDQpIb3dldmVyLCBob3cg dGhlIFJTIGF1dGhlbnRpY2F0ZXMgdGhlIFVzZXIgc2hvdWxkIGJlIHdpdGhpbiB0aGUgc2NvcGUu DQpUaGVyZSBhcmUgYSBwbGV0aG9yYSBvZiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLCBhbmQg c3RhbmRhcmRpemluZyBob3cgdGhlIHVzZXIgYXV0aGVudGljYXRlcyBpcyBub3QgcmVxdWlyZWQg Zm9yIGludGVyb3AuDQpTaGFyaW5nIHRoZSAicXVhbGl0eSIgb2YgdGhlIGF1dGhlbnRpY2F0aW9u IGlzIGFuIGFyZWEgb2Ygc3RhbmRhcmRpemF0aW9uIHRoYXQgaGFzIGJlZW4gZG9uZSBpbiBPcGVu SUQgQ29ubmVjdCwgYW5kIEkgdGhpbmsgc2hvdWxkIGJlIGluY2x1ZGVkIGluIEdOQVAuDQoNCkhh dmluZyBzYWlkIHRoYXQsIHRoZSBDbGllbnQgY291bGQgb3B0aW9uYWxseSB1c2UgRklETyB0byBh dXRoZW50aWNhdGUgdGhlIFVzZXIgYW5kIHNvbWVob3cgdHJhbnNtaXQgdGhhdCB0byB0aGUgQVMu DQoNCk5vLiBUaGUgUlMgQ2xpZW50IGNvdWxkIG9wdGlvbmFsbHkgdXNlIEZJRE8gdG8gYXV0aGVu dGljYXRlIHRoZSBVc2VyLiBTaW5jZSBGSURPIGRvZXMgbm90IG1hbmRhdGUgYW55IEFTLCB0aGVy ZSBpcyBubyBpbnRlcmFjdGlvbiB3aXRoIGFueSBBUyBhdCB0aGF0IHN0YWdlLg0KDQpEZW5pcw0K W0ltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLl3hkKcNCg0KT24gVGh1LCBBdWcgMTMsIDIwMjAgYXQg MTA6MzEgQU0gRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVl LmZyPj4gd3JvdGU6DQpUaGlzIHRvcGljIGhhcyBhbHJlYWR5IGJlZW4gdGFja2xlZCBvbiB0aGUg bGlzdCwgYnV0IEkgb3BlbiBhIG5ldyB0aHJlYWQgZm9yIGl0Lg0KDQpJbiBPQXV0aCAyLjAsIG9u ZSBvZiB0aGUgZ29hbHMgd2FzIHRvIGdldCByaWQgb2YgSURzIGFuZCBwYXNzd29yZHMuIFNpbmNl IHRoZSBzb2x1dGlvbiBpbiBPQXV0aCAyLjAgd2FzIHRvIHVzZSBhY2Nlc3MgdG9rZW5zLA0KdGhl cmUgaGF2ZSBiZWVuIHVzZWQgZXZlcnl3aGVyZSwgZXZlbiB3aGVuIHRoZXkgd2VyZSBub3Qgc3Ry aWN0bHkgbmVlZGVkLg0KSXQgaXMgYWxzbyBwb3NzaWJsZSB0byBnZXQgcmlkIG9mIElEcyBhbmQg cGFzc3dvcmRzIHVzaW5nIEZJRE8uIEZJRE8gZGlzY2xvc2VzIG5vIHByaXZhdGUgaW5mb3JtYXRp b24gYXQgYWxsIGFib3V0IHRoZSB1c2VyDQphbmQgbm8gdHJ1c3QgcmVsYXRpb25zaGlwcyBuZWVk IHRvIGJlIGRlZmluZWQgc2luY2UgdGhlcmUgaXMgbm8gQVMuDQpGSURPIHNob3VsZCBiZSBvbmUg YWxsb3dlZCBwb3NzaWJpbGl0eSBmb3IgdGhlIHVzZXIgYXV0aGVudGljYXRpb24uIEluIHRoZSBj YXNlIG9mIEZJRE8sIHRoZSB1c2VyIGlzIGF1dGhlbnRpY2F0ZWQgdW5kZXIgYSBwc2V1ZG9ueW0N CnNwZWNpZmljIHRvIHRoZSBSUy4gSXQgbWF5IG9ic2VydmVkIHRoYXQgdGhlcmUgaXMgbm8gZXF1 aXZhbGVudCBpbiBPQXV0aCBiZWNhdXNlIG9mIHRoZSB0d28gZGlmZmVyZW50IHNlbWFudGljcyBv ZiB0aGUgc3ViamVjdCBjbGFpbS4NClJGQyA3NTE5IHN0YXRlczoNClRoZSAic3ViIiAoc3ViamVj dCkgY2xhaW0gaWRlbnRpZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQgaXMgdGhlIHN1YmplY3Qgb2Yg dGhlIEpXVC4gIFRoZSBjbGFpbXMgaW4gYSBKV1QgYXJlIG5vcm1hbGx5IHN0YXRlbWVudHMgYWJv dXQgdGhlIHN1YmplY3QuDQpUaGUgc3ViamVjdCB2YWx1ZSBNVVNUIGVpdGhlciBiZSBzY29wZWQg dG8gYmUgbG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBiZSBn bG9iYWxseSB1bmlxdWUuDQpJbiBvbmUgY2FzZSwgaXQgaXMgcG9zc2libGUgdG8gbGluayB0aGUg c3ViamVjdCBjbGFpbSBvZiB0d28gdXNlcnMgYmV0d2VlbiB0d28gUlNzIChpLmUuIHVzaW5nIGEg bG9jYWxseSB1bmlxdWUgaWRlbnRpZmllciBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVyKQ0K d2hpbGUgaW4gdGhlIG90aGVyIGNhc2UgKGkuZS4gdXNpbmcgYSBnbG9iYWxseSB1bmlxdWUgaWRl bnRpZmllcikgaXQgaXMgcG9zc2libGUsIGluIGFkZGl0aW9uLCB0byBsaW5rIHRoZSBzdWJqZWN0 IGNsYWltIGJldHdlZW4gb25lIFJTIGFuZCBhbnkgb3RoZXIgc2VydmVyDQooaS5lLiBub3Qgc3Vw cG9ydGluZyBPQXV0aCkgdGhhdCBpcyB1c2luZyB0aGUgc2FtZSBnbG9iYWxseSB1bmlxdWUgaWRl bnRpZmllci4NCk5vbmUgb2YgdGhlc2UgdHdvIHNlbWFudGljcyBmaXQgd2l0aCB0aGUgRklETyB1 c2UgY2FzZSB3aGVyZSB0aGUgc3ViamVjdCB2YWx1ZSBpcyBzY29wZWQgdG8gYmUgbG9jYWxseSB1 bmlxdWUgaW4gdGhlIGNvbnRleHQgb2Ygb25lIFJTLg0KSGVuY2UsIHRoZSBsaW5rYWdlIG9mIHVz ZXJzIGJldHdlZW4gdHdvIFJTcyAob3IgYmV0d2VlbiBvbmUgUlMgYW5kIGFueSBvdGhlciBzZXJ2 ZXIpIGJlY29tZXMgaW1wb3NzaWJsZS4NClRoZXJlIGFyZSBjYXNlcyB3aGVyZSBhIHVzZXIgd291 bGQgbGlrZSB0byBlbmpveSB0aGUgdW5saW5rZWFiaWxpdHkgcHJvcGVydGllcyBvZiBGSURPIHdo aWNoIGNhbm5vdCBiZSBtZXQgdXNpbmcgdGhlIGNsYWltcyBjdXJyZW50bHkgZGVmaW5lZCBpbiBP QXV0aC4NCkRlbmlzDQotLQ0KVFhBdXRoIG1haWxpbmcgbGlzdA0KVFhBdXRoQGlldGYub3JnPG1h aWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3R4YXV0aA0KDQoNCg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnRzIGFuZCBtYXkgYmUgcHJpdmls ZWdlZCwgY29uZmlkZW50aWFsIG9yIG90aGVyd2lzZSBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVu ZGVyIGxhdy4gQW55IGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3Igb3RoZXIgdXNlIGJ5IGFueW9u ZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5LCBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoaXMgZW1haWwgYW5kIGl0cyBh dHRhY2htZW50cy4NCg== --_000_75441F90C6A54BADB49EF4FCC2DE55C9securekeycom_ Content-Type: text/html; charset="utf-8" Content-ID: <73537D419D2BDD46B53F80AB454ACB06@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhpbmsgYWxsb3dpbmcgYSB0cnVzdGVkIENsaWVudCB0byBhdXRoTiB0aGUgZW5kIHVzZXIgYW5k IGhhdmUgdGhlIEFTIHRydXN0IHRoYXQgYXV0aGVudGljYXRpb24gaXMgYW4gaW1wb3J0YW50IGZl YXR1cmUsIGVzcGVjaWFsbHkgZm9yIG1vYmlsZSBjbGllbnQgb3IgaW4gdGhlIGV4YW1wbGUgb2Yg RklETy9XZWJBdXRoTi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2 ZSBjYXB0dXJlZCB0aGUgdXNlIGNhc2UgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ2VuZXJh bC93aWtpL0NsaWVudC1jYW4tQXV0aE4tRW5kLVVzZXIiPmh0dHBzOi8vZ2l0aHViLmNvbS9pZXRm LXdnLWduYXAvZ2VuZXJhbC93aWtpL0NsaWVudC1jYW4tQXV0aE4tRW5kLVVzZXI8L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1WPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VFhBdXRoICZsdDt0eGF1dGgtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIERlbmlzICZsdDtkZW5pcy5pZXRmQGZyZWUu ZnImZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgQXVndXN0IDE0LCAyMDIwIGF0IDY6MDUg QU08YnI+DQo8Yj5UbzogPC9iPkRpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1dGhA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbR05BUF0gU3VwcG9ydCBvZiBG SURPPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5IaSBEaWNrLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9BdXRoIDIuMCBnb2FsIHdhcyBub3QgdG8gZ2V0IHJpZCBvZiB1c2VybmFtZXMg YW5kIHBhc3N3b3Jkcy4gSXQgd2FzIHRvIHN0b3Agc2l0ZSBBIGZyb20gYXNraW5nIGZvciB0aGUg dXNlcidzIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBhdCBzaXRlIEIgc28gdGhhdCBzaXRlIEEgY291 bGQgYWNjZXNzIHJlc291cmNlcyBhdCBzaXRlIEIuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkhvdyB0aGUgQVMgYXV0aGVudGljYXRlcyB0aGUgVXNlciBpcyBv dXQgb2Ygc2NvcGUsIGFuZCBJIHRoaW5rJm5ic3A7c2hvdWxkIGJlIG91dCBvZiBzY29wZS4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPk1heWJlLCBtYXkgYmUgbm90LiBTb21lIG1lYW5zIG9mIGF1dGhl bnRpY2F0aW9uIGJldHdlZW4gYSBVc2VyIGFuZCBhbiBBUyBjb3VsZCBiZSByZWNvbW1lbmRlZCBh bmQgZG9jdW1lbnRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPkhvd2V2ZXIsIGhvdyB0aGUgUlMgYXV0aGVudGljYXRlcyB0aGUgVXNlciBzaG91bGQgYmUg d2l0aGluIHRoZSBzY29wZS48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGVyZSBhcmUgYSBwbGV0 aG9yYSBvZiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLCBhbmQgc3RhbmRhcmRpemluZyBob3cg dGhlIHVzZXIgYXV0aGVudGljYXRlcyBpcyBub3QgcmVxdWlyZWQmbmJzcDtmb3IgaW50ZXJvcC4N Cjxicj4NClNoYXJpbmcgdGhlICZxdW90O3F1YWxpdHkmcXVvdDsgb2YgdGhlIGF1dGhlbnRpY2F0 aW9uIGlzIGFuIGFyZWEgb2Ygc3RhbmRhcmRpemF0aW9uIHRoYXQgaGFzIGJlZW4gZG9uZSBpbiBP cGVuSUQgQ29ubmVjdCwgYW5kIEkgdGhpbmsgc2hvdWxkIGJlIGluY2x1ZGVkIGluIEdOQVAuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhhdmluZyBz YWlkIHRoYXQsIHRoZSBDbGllbnQgY291bGQgb3B0aW9uYWxseSB1c2UgRklETyB0byBhdXRoZW50 aWNhdGUgdGhlIFVzZXIgYW5kIHNvbWVob3cgdHJhbnNtaXQgdGhhdCB0byB0aGUgQVMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Tm8uIFRoZSBSUyBDbGllbnQgY291bGQgb3B0aW9uYWxseSB1c2UgRklE TyB0byBhdXRoZW50aWNhdGUgdGhlIFVzZXIuIFNpbmNlIEZJRE8gZG9lcyBub3QgbWFuZGF0ZSBh bnkgQVMsIHRoZXJlIGlzIG5vIGludGVyYWN0aW9uIHdpdGggYW55IEFTIGF0IHRoYXQgc3RhZ2Uu PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EZW5pczxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGNtIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMyIiBoZWlnaHQ9IjMyIiBzdHlsZT0i d2lkdGg6LjMzMzNpbjtoZWlnaHQ6LjMzMzNpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6 fldSRDAwMDMuanBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPk9uIFRodSwgQXVnIDEzLCAyMDIwIGF0IDEwOjMxIEFNIERlbmlz ICZsdDs8YSBocmVmPSJtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIj5kZW5pcy5pZXRmQGZyZWUu ZnI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+VGhpcyB0b3BpYyBoYXMgYWxyZWFkeSBiZWVuIHRhY2tsZWQgb24gdGhlIGxpc3QsIGJ1dCBJ IG9wZW4gYSBuZXcgdGhyZWFkIGZvciBpdC48YnI+DQo8YnI+DQpJbiBPQXV0aCAyLjAsIG9uZSBv ZiB0aGUgZ29hbHMgd2FzIHRvIGdldCByaWQgb2YgSURzIGFuZCBwYXNzd29yZHMuIFNpbmNlIHRo ZSBzb2x1dGlvbiBpbiBPQXV0aCAyLjAgd2FzIHRvIHVzZSBhY2Nlc3MgdG9rZW5zLA0KPGJyPg0K dGhlcmUgaGF2ZSBiZWVuIHVzZWQgZXZlcnl3aGVyZSwgZXZlbiB3aGVuIHRoZXkgd2VyZSBub3Qg c3RyaWN0bHkgbmVlZGVkLiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JdCBpcyBhbHNvIHBvc3Np YmxlIHRvIGdldCByaWQgb2YgSURzIGFuZCBwYXNzd29yZHMgdXNpbmcgRklETy4gRklETyBkaXNj bG9zZXMgbm8gcHJpdmF0ZSBpbmZvcm1hdGlvbiBhdCBhbGwgYWJvdXQgdGhlIHVzZXINCjxicj4N CmFuZCBubyB0cnVzdCByZWxhdGlvbnNoaXBzIG5lZWQgdG8gYmUgZGVmaW5lZCBzaW5jZSB0aGVy ZSBpcyBubyBBUy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZJRE8gc2hvdWxkIGJlIG9uZSBhbGxv d2VkIHBvc3NpYmlsaXR5IGZvciB0aGUgdXNlciBhdXRoZW50aWNhdGlvbi4gSW4gdGhlIGNhc2Ug b2YgRklETywgdGhlIHVzZXIgaXMgYXV0aGVudGljYXRlZCB1bmRlciBhIHBzZXVkb255bQ0KPGJy Pg0Kc3BlY2lmaWMgdG8gdGhlIFJTLiBJdCBtYXkgb2JzZXJ2ZWQgdGhhdCB0aGVyZSBpcyBubyBl cXVpdmFsZW50IGluIE9BdXRoIGJlY2F1c2Ugb2YgdGhlIHR3byBkaWZmZXJlbnQgc2VtYW50aWNz IG9mIHRoZSBzdWJqZWN0IGNsYWltLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SRkMgNzUxOSBzdGF0 ZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlICZxdW90O3N1YiZxdW90OyAoc3ViamVjdCkg Y2xhaW0gaWRlbnRpZmllcyB0aGUgcHJpbmNpcGFsIHRoYXQgaXMgdGhlIHN1YmplY3Qgb2YgdGhl IEpXVC4mbmJzcDsgVGhlIGNsYWltcyBpbiBhIEpXVCBhcmUgbm9ybWFsbHkgc3RhdGVtZW50cyBh Ym91dCB0aGUgc3ViamVjdC4mbmJzcDsNCjxicj4NClRoZSBzdWJqZWN0IHZhbHVlIE1VU1QgZWl0 aGVyIGJlIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUg aXNzdWVyIG9yIGJlIGdsb2JhbGx5IHVuaXF1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+SW4gb25lIGNhc2UsIGl0IGlzIHBvc3NpYmxlIHRvIGxpbmsgdGhlIHN1YmplY3Qg Y2xhaW0gb2YgdHdvIHVzZXJzIGJldHdlZW4gdHdvIFJTcyAoaS5lLiB1c2luZyBhIGxvY2FsbHkg dW5pcXVlIGlkZW50aWZpZXIgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlcikNCjxicj4NCndo aWxlIGluIHRoZSBvdGhlciBjYXNlIChpLmUuIHVzaW5nIGEmbmJzcDtnbG9iYWxseSB1bmlxdWUg aWRlbnRpZmllcikgaXQgaXMgcG9zc2libGUsIGluIGFkZGl0aW9uLCB0byBsaW5rIHRoZSBzdWJq ZWN0IGNsYWltIGJldHdlZW4gb25lIFJTIGFuZCBhbnkgb3RoZXIgc2VydmVyDQo8YnI+DQooaS5l LiBub3Qgc3VwcG9ydGluZyBPQXV0aCkgdGhhdCBpcyB1c2luZyB0aGUgc2FtZSBnbG9iYWxseSB1 bmlxdWUgaWRlbnRpZmllci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Tm9uZSBvZiB0aGVzZSB0d28g c2VtYW50aWNzIGZpdCB3aXRoIHRoZSBGSURPIHVzZSBjYXNlIHdoZXJlIHRoZSBzdWJqZWN0IHZh bHVlIGlzIHNjb3BlZCB0byBiZSBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiBvbmUg UlMuDQo8YnI+DQpIZW5jZSwgdGhlIGxpbmthZ2Ugb2YgdXNlcnMgYmV0d2VlbiB0d28gUlNzIChv ciBiZXR3ZWVuIG9uZSBSUyBhbmQgYW55IG90aGVyIHNlcnZlcikgYmVjb21lcyBpbXBvc3NpYmxl LiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ VGhlcmUgYXJlIGNhc2VzIHdoZXJlIGEgdXNlciB3b3VsZCBsaWtlIHRvIGVuam95IHRoZSB1bmxp bmtlYWJpbGl0eSBwcm9wZXJ0aWVzIG9mIEZJRE8gd2hpY2ggY2Fubm90IGJlIG1ldCB1c2luZyB0 aGUgY2xhaW1zIGN1cnJlbnRseSBkZWZpbmVkIGluIE9BdXRoLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5EZW5pczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0gPGJyPg0KVFhBdXRoIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpUWEF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5U WEF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBpZD0iYm9keSIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDsgY29sb3I6ZGFya2dyYXk7IGxpbmUtaGVpZ2h0OjEwcHQ7IGZvbnQt ZmFtaWx5OiAnQXJpYWwnLCd0aW1lcyByb21hbicsc2VyaWY7Ij4NClRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50cyBhbmQgbWF5IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBvciBvdGhlcndpc2UgZXhl bXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBsYXcuIEFueSBkaXN0cmlidXRpb24sIHByaW50aW5n IG9yIG90aGVyIHVzZSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IGlzIHByb2hpYml0ZWQuDQogSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBhbmQgcGVybWFuZW50bHkgZGVs ZXRlIHRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cy48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_75441F90C6A54BADB49EF4FCC2DE55C9securekeycom_-- From nobody Fri Aug 14 06:14:45 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 058253A10F0 for ; Fri, 14 Aug 2020 06:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bAUgYS2eHLDq for ; Fri, 14 Aug 2020 06:14:43 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4833A10EC for ; Fri, 14 Aug 2020 06:14:42 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d66 with ME id FREf230042bcEcA03REfFc; Fri, 14 Aug 2020 15:14:40 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 15:14:40 +0200 X-ME-IP: 90.79.51.120 To: Mike Varley Cc: "txauth@ietf.org" References: <855a47e3-5460-83b5-a452-52773e9bbcfd@free.fr> <75441F90-C6A5-4BAD-B49E-F4FCC2DE55C9@securekey.com> From: Denis Message-ID: Date: Fri, 14 Aug 2020 15:14:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <75441F90-C6A5-4BAD-B49E-F4FCC2DE55C9@securekey.com> Content-Type: multipart/alternative; boundary="------------105B4C19080E0A5385E09546" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 13:14:45 -0000 This is a multi-part message in MIME format. --------------105B4C19080E0A5385E09546 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mike, Please open a new thread if you want to discuss this topic as it is unrelated to FIDO. Denis > I think allowing a trusted Client to authN the end user and have the > AS trust that authentication is an important feature, especially for > mobile client or in the example of FIDO/WebAuthN. > > I have captured the use case here: > > https://github.com/ietf-wg-gnap/general/wiki/Client-can-AuthN-End-User > > MV > > *From: *TXAuth on behalf of Denis > > *Date: *Friday, August 14, 2020 at 6:05 AM > *To: *Dick Hardt > *Cc: *"txauth@ietf.org" > *Subject: *Re: [GNAP] Support of FIDO > > Hi Dick, > > OAuth 2.0 goal was not to get rid of usernames and passwords. It > was to stop site A from asking for the user's username and > password at site B so that site A could access resources at site B. > > How the AS authenticates the User is out of scope, and I > think should be out of scope. > > Maybe, may be not. Some means of authentication between a User and an > AS could be recommended and documented. > > However, how the RS authenticates the User should be within the scope. > > There are a plethora of authentication mechanisms, and > standardizing how the user authenticates is not required for interop. > Sharing the "quality" of the authentication is an area of > standardization that has been done in OpenID Connect, and I think > should be included in GNAP. > > Having said that, the Client could optionally use FIDO to > authenticate the User and somehow transmit that to the AS. > > No. The RS Client could optionally use FIDO to authenticate the User. > Since FIDO does not mandate any AS, there is no interaction with any > AS at that stage. > > Denis > > Image removed by sender.ᐧ > > On Thu, Aug 13, 2020 at 10:31 AM Denis > wrote: > > This topic has already been tackled on the list, but I open a > new thread for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and > passwords. Since the solution in OAuth 2.0 was to use access > tokens, > there have been used everywhere, even when they were not > strictly needed. > > It is also possible to get rid of IDs and passwords using > FIDO. FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is > no AS. > > FIDO should be one allowed possibility for the user > authentication. In the case of FIDO, the user is authenticated > under a pseudonym > specific to the RS. It may observed that there is no > equivalent in OAuth because of the two different semantics of > the subject claim. > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is > the subject of the JWT.  The claims in a JWT are normally > statements about the subject. > The subject value MUST either be scoped to be locally > unique in the context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two > users between two RSs (i.e. using a locally unique identifier > in the context of the issuer) > while in the other case (i.e. using a globally unique > identifier) it is possible, in addition, to link the subject > claim between one RS and any other server > (i.e. not supporting OAuth) that is using the same globally > unique identifier. > > None of these two semantics fit with the FIDO use case where > the subject value is scoped to be locally unique in the > context of one RS. > Hence, the linkage of users between two RSs (or between one RS > and any other server) becomes impossible. > > There are cases where a user would like to enjoy the > unlinkeability properties of FIDO which cannot be met using > the claims currently defined in OAuth. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > This email and any attachments are for the sole use of the intended > recipients and may be privileged, confidential or otherwise exempt > from disclosure under law. Any distribution, printing or other use by > anyone other than the intended recipient is prohibited. If you are not > an intended recipient, please contact the sender immediately, and > permanently delete this email and its attachments. > --------------105B4C19080E0A5385E09546 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Mike,

Please open a new thread if you want to discuss this topic as it is unrelated to FIDO.

Denis

I think allowing a trusted Client to authN the end user and have the AS trust that authentication is an important feature, especially for mobile client or in the example of FIDO/WebAuthN.

I have captured the use case here:

https://github.com/ietf-wg-gnap/general/wiki/Client-can-AuthN-End-User

 

MV

 

From: TXAuth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
Date: Friday, August 14, 2020 at 6:05 AM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [GNAP] Support of FIDO

 

Hi Dick,

 

OAuth 2.0 goal was not to get rid of usernames and passwords. It was to stop site A from asking for the user's username and password at site B so that site A could access resources at site B.

 

How the AS authenticates the User is out of scope, and I think should be out of scope.

Maybe, may be not. Some means of authentication between a User and an AS could be recommended and documented.

However, how the RS authenticates the User should be within the scope.

There are a plethora of authentication mechanisms, and standardizing how the user authenticates is not required for interop.
Sharing the "quality" of the authentication is an area of standardization that has been done in OpenID Connect, and I think should be included in GNAP.

 

Having said that, the Client could optionally use FIDO to authenticate the User and somehow transmit that to the AS.

No. The RS Client could optionally use FIDO to authenticate the User. Since FIDO does not mandate any AS, there is no interaction with any AS at that stage.

Denis

Image removed by sender.ᐧ

 

On Thu, Aug 13, 2020 at 10:31 AM Denis <denis.ietf@free.fr> wrote:

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
and no trust relationships need to be defined since there is no AS.

FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.

RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.

None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible. 

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis

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

 

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.


--------------105B4C19080E0A5385E09546-- From nobody Fri Aug 14 06:23:55 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 AB04E3A1109 for ; Fri, 14 Aug 2020 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=udelt-no.20150623.gappssmtp.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 EzJPWd0kghi4 for ; Fri, 14 Aug 2020 06:23:50 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 0FC3B3A1120 for ; Fri, 14 Aug 2020 06:23:49 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id z18so7537556otk.6 for ; Fri, 14 Aug 2020 06:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJ0TB3U1783dDJ1rXsd2Gy5mnUWZf4d6XXsPX/JKqCg=; b=CEo+dgUu+Drcy/uzEz5vwEzd67NPLmZBmEaxrQE9EnHELpE+pa0mzIOyaOVlgMG/dP 0p3U7mWU4J7q1oJwjRszZuzQh5RW50Ke4Sze3tuxoRba/ZkVQDHKanODN1DkzE/zcri8 zVlpvtv+FgtGbmajiTqZtye3gtUjvvkODQSXIi2BR13qMo0eEr8UHw+XvnAIajS02FKH +TMnSDrN7KztNzcM+7CvBpP1PD2jkrOWzxZjDxgC4PUZXcHm7rorS1aSZi623RIQ/jAQ XCdVVFKkzzn4X3EY6HKrBqTNfPGzh3cXb5MnbGlXbdNtrdb9JBovx1ynxIVg4j5bHN+l GLlw== 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=DJ0TB3U1783dDJ1rXsd2Gy5mnUWZf4d6XXsPX/JKqCg=; b=j9l5stsFMIyA0DEIK9qjveBQvhvQ7d28aDljByNqGibS5xVSSh1RqwmQva+Dv6kxLr KZJSjkht8W79jdCXZQS/ZopiPgDO200KjmeMaEEue0BSuhSszND4g/R1lJ+nsqajgLi1 yDfwbuFttojKLpJ0dlvLXAOaLd04SoVEiT6qZHKXAWrcU7cK0eHEKM1LlKq4VvOOJxs+ U+9JxSsHOhNHlZcOTAGz18dQ4D1SEITy/U435Jdr3grCkGPIly3QScQR7qk+Z55v4jhC nbkMGDZdg1DkR0LbxqmLMXZ8XL4q85m5R9pQ4Xean6tDKkQYTNvct/gZogblg0oMbxfG 7gOA== X-Gm-Message-State: AOAM532gWXBUgtV1PCqoPf9N2VMpxBLeC1U2FXN/iXFmSB/A0DAqWk5v NFROJOsjazDAWgWV4NbTC4MaaQkEnf/uuKcst3sq2A== X-Google-Smtp-Source: ABdhPJyoLDUu3MYK5ehXGXXBGG47IA59c5Llv/J+czE1XmmebhABT/uHlulD9LxR8X6jYndDq+7uuIh0udTWaH+Qbgg= X-Received: by 2002:a9d:19a3:: with SMTP id k32mr1916908otk.273.1597411428488; Fri, 14 Aug 2020 06:23:48 -0700 (PDT) MIME-Version: 1.0 References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> In-Reply-To: <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> From: Steinar Noem Date: Fri, 14 Aug 2020 15:23:38 +0200 Message-ID: To: Denis Cc: nadalin@prodigy.net, txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c16c7e05acd65401" Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 13:23:53 -0000 --000000000000c16c7e05acd65401 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, I have always perceived U2F (which I think has been replaced by FIDO2/CTAP/WebAuthn) as just a pure second factor and not an authentication in itself. I may be wrong, but from my understanding U2F makes sense in combination with user authentication, but not as a stand-alone solution. Steinar fre. 14. aug. 2020 kl. 12:04 skrev Denis : > Hi Tony, > > Dennis, not all the way correct > > > > - It is also possible to get rid of IDs and passwords using FIDO. FIDO > discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS > > Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D PII= , there can be > all sorts of information passed in ClientData field of the FIDO response, > not desirable but perfectly OK > > > > - None of these two semantics fit with the FIDO use case where the > subject value is scoped to be locally unique in the context of one RS. > Hence, the linkage of users between two RSs (or between one RS and any > other server) becomes impossible > > > > There is nothing that prohibits the RS from sharing registration > information between RS > > I am speaking of FIDO U2F where there are two main phases: registration > and authentication. > > The U2F device gives the public key and a Key Handle to the origin online > service or website during the user registration step. > Later, when the user performs an authentication, the origin online servic= e > or website sends the Key Handle back to the U2F device > via the browser. The U2F device uses the Key Handle to identify the user'= s > private key, and creates a signature which is sent back > to the origin to verify the presence of the U2F device. Thus, the Key > Handle is simply an identifier of a particular key on the U2F device. > > There is no other registration information needed. Sharing such an > information between RSs does not allow to link user accounts. > > Denis > > > > *From:* TXAuth *On > Behalf Of *Denis > *Sent:* Thursday, August 13, 2020 10:31 AM > *To:* txauth@ietf.org > *Subject:* [GNAP] Support of FIDO > > > > This topic has already been tackled on the list, but I open a new thread > for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since > the solution in OAuth 2.0 was to use access tokens, > there have been used everywhere, even when they were not strictly needed. > > It is also possible to get rid of IDs and passwords using FIDO. FIDO > discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS. > > FIDO should be one allowed possibility for the user authentication. In th= e > case of FIDO, the user is authenticated under a pseudonym > specific to the RS. It may observed that there is no equivalent in OAuth > because of the two different semantics of the subject claim. > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is the subject of > the JWT. The claims in a JWT are normally statements about the subject. > The subject value MUST either be scoped to be locally unique in the > context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two users betwee= n > two RSs (i.e. using a locally unique identifier in the context of the > issuer) > while in the other case (i.e. using a globally unique identifier) it is > possible, in addition, to link the subject claim between one RS and any > other server > (i.e. not supporting OAuth) that is using the same globally unique > identifier. > > None of these two semantics fit with the FIDO use case where the subject > value is scoped to be locally unique in the context of one RS. > > Hence, the linkage of users between two RSs (or between one RS and any > other server) becomes impossible. > > There are cases where a user would like to enjoy the unlinkeability > properties of FIDO which cannot be met using the claims currently defined > in OAuth. > > Denis > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --000000000000c16c7e05acd65401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis, I have always perceived U2F (which I think has b= een replaced by FIDO2/CTAP/WebAuthn) as just a pure second factor and not a= n authentication in itself.
I may be wrong, but from my understanding U= 2F makes sense in combination with user authentication, but not as a stand-= alone solution.

<mvh>Steinar</mvh>

fre. 14. aug. 2020 kl. 12:04 skrev Denis <denis.ietf@free.fr>:
=20 =20 =20
Hi Tony,
=20 =20 =20

Dennis, not all the way correct

=C2=A0

  • It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
    and no trust relationships need to be defined since there is no AS

Depends on if you only consider =E2=80=9Cpri= vate information=E2=80=9D PII, there can be all sorts of information p= assed in ClientData field of the FIDO response, not desirable but perfectly OK

=C2=A0

  • None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
    Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible    =

=C2=A0

There is nothing that prohibits the RS from sharing registration information between RS

I am speaking of FIDO U2F where there are two main phases: registration and authentication.

The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature whic= h is sent back
to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

Denis

=C2=A0

From: TXAuth = <txauth-bounces@ietf.org> On Behalf Of Denis
Sent: Thursday, August 13, 2020 10:31 AM
To: txauth@ietf.org
Subject: [GNAP] Support of FIDO

=C2=A0

This topic has already been tackled on the list, but I open a new thread for it.

In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
there have been used everywhere, even when they were not strictly needed.

It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
and no trust relationships need to be defined since there is no AS.

FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.

RFC 7519 states:

The "sub" (subject) claim identifies the principal that is the subject of the JWT.=C2=A0 The claims in a JWT are normally statements about the subject.=C2=A0
The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
while in the other case (i.e. using a=C2=A0globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
(i.e. not supporting OAuth) that is using the same globally unique identifier.

None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.

There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.

Denis


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


--
Vennlig hilsen=

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
--000000000000c16c7e05acd65401-- From nobody Fri Aug 14 07:15: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 4BD383A112F for ; Fri, 14 Aug 2020 07:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=prodigy.net 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 PUE7ZU_GH-GY for ; Fri, 14 Aug 2020 07:15:06 -0700 (PDT) Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (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 29DB83A0C5E for ; Fri, 14 Aug 2020 07:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597414505; bh=kBSEtcoyS3Xoy9t5c1mVzGEGjE4HWjkveK+BUiNGuTU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From:Subject; b=VpZr1cmimNr9DOrbdWl5AgutMqQJU5qcCI2tXEuhxQEghzj6OOBTOOvcFxj1pN7fZrniqx01oaqH5dWHDbGBsc8PcRKY9b8yOcJwdp3dOjJI1Gia2nxluAT0clGP8iHORQGc//kFaPIx/6n75JCyhhKzmlRhKpg+qkM+Xo6SDwLyT1S78X752/5pe9zXRn8EJHXFb2nFeNwsSosGxyEeol+ztnNOOpofAAsuuVgBKiFIzLOz7xhx6cacjYMVjTzNS4BylHLUgQmvC2SUGsIXA0P2FiV3Lg8NgdKCDFlwtHW1C4anCyGAGuENWtdtRPkbxRViCFGt4yhBQXmVr3bouA== X-YMail-OSG: G2q0ddIVM1nW2HR1QgnOTtdlhBU95pKFoujDU6_IS72DmfoJLosaKdbR2Mlh9Bk DxrijoX_CV3C1BC3fmcwQm0q.Kzmip0lhjuSVWN.SzVrft0iOecDNmdOTVyQeopE695tIcRljpHK 291CR8CfMa7FH6CoGGqaszhMb1NXX5Opz3CVjmdA7rmcMPPYIOBW1E2dJaD9ul4q9SI2VmXAsCMY huTqY8QlA8J2hU8GlOkBoc5iXeOIY5lDPxvKRpzBugk1NWdKRlnNG1_fJDjTmHqlCBjXuOFfmG5t 14Hg7_1nThh056kOk3TSFa3nMK0FCHc80K1jeRVaQjbV5fL48BhMAvwZoaJiogj1mhRGTpI8ut1E sqQqIjSKcx5ykz9gLagM2WgfsOyoSBl.F5Lj6O4YOBllqVII6rYmhPpTpxIArskroFMh8C88qq9n qx_tgr7DNzRMx86WpO2HHkXKuBcG2N0KSnVjY5s7wF.ykGZR_YOH4uVTmff58XbaS95miWe3hxWz WvU3xCufLfvVgSWDqwh67pPI9kxzvub8ZiLadH75TxStoo4VVdK7KgZgkSvx9XOutTWYayJnp1Dn xaWvJ5P6NAgDkOMifxsWuqpmp3ZjDkc_KFqX2ePCROULcnlbbqohKnBMambDYmCkP9kWvq1BMiUM Y3wW91mdb5GaDOQjN.e1cvLxCWpSiklJVYrnkyPVAitLqBuEGVcH4RcaG5sk8qAChr79AmK_XCMA RQgobO5yIGmmqAl68URirX6rVa6H0pAbV.VtBQc2rLPxDreZqmVq2enVFTeWtmxNaMJLRsSP4iUp hMCZZcS7PKqzdC2A029xYD_EH1_10HwqgRtgktz7DE5FijJD3r7Vw6KAwDusuGxCkmbkvhltlZQ1 REczFjsRcIUpDfxyfFZ2yvqsgn7gPaSl.6JlshR3TbDxN4OcXFaNFSbrFqFAwJmOT40uXIyyaULK WHAvKmJt2GEgpwWKBuIRLRli0rk8mFu9Q3wxWU5YWSiulSuLtcVi1BFW6xJmxYLiRLkvvpketpA9 88C75hCQavPY0hsdZ34sz3P9D44bpKxiHdqIeTRG5nGuT9TzaptsBkydNtwYeUtWPDsONuShvmhs eV.o7qgichl1MNgwZv1pcO4FLDABZwtE1t1eBOFk4KVJTICtqnbKQk_woxqtvD45ouWxeyEXeSTb x.8htVX2q_bW6_c9gKM0G4Gggqa4E1PQjalXOTsMqSPTz4MoEkScDsUCa0GxIh5jGTNPtE74bhKk YlWA4bFki.rOuMD0500OyAqG561SJduzdh24zBy6YagtS1BQDnTYzVr35IGDzGKF_5rWDHE07jg_ vuphq1p.M0kI_0iFwJ40MAS6Kn2tf1OwPFKk87r8i_4PDqA7bjWvHQpyTPXNJf3TQbOIvn4EgtfG PeOmlIncDNzOqWLbBjLzJfDu0xS0qnUGrHtWRs_3bprs7nKyOyYiNXearw57xKCyWKVTTuVVXd8o 2.pSijS31c7qdXQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 14 Aug 2020 14:15:05 +0000 Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3ce8af68f0e3c19c33fc7ee939b1bfb4; Fri, 14 Aug 2020 14:15:00 +0000 (UTC) From: To: "'Steinar Noem'" , "'Denis'" Cc: References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> In-Reply-To: Date: Fri, 14 Aug 2020 07:14:58 -0700 Message-ID: <014601d67245$4b4066b0$e1c13410$@prodigy.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01D6720A.9EE22AF0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAJA1Hv+AlIHM6cCNKqjJKlKPBFA Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 14:15:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0147_01D6720A.9EE22AF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Correct U2F is not passwordless like FIDO2 or UAF =20 From: TXAuth On Behalf Of Steinar Noem Sent: Friday, August 14, 2020 6:24 AM To: Denis Cc: txauth@ietf.org; nadalin@prodigy.net Subject: Re: [GNAP] Support of FIDO =20 Hi Denis, I have always perceived U2F (which I think has been replaced = by FIDO2/CTAP/WebAuthn) as just a pure second factor and not an = authentication in itself. I may be wrong, but from my understanding U2F makes sense in combination = with user authentication, but not as a stand-alone solution. =20 Steinar =20 fre. 14. aug. 2020 kl. 12:04 skrev Denis >: Hi Tony,=20 Dennis, not all the way correct =20 * It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D = PII, there can be all sorts of information passed in ClientData field of = the FIDO response, not desirable but perfectly OK =20 * None of these two semantics fit with the FIDO use case where the = subject value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible =20 There is nothing that prohibits the RS from sharing registration = information between RS=20 I am speaking of FIDO U2F where there are two main phases: registration = and authentication. The U2F device gives the public key and a Key Handle to the origin = online service or website during the user registration step.=20 Later, when the user performs an authentication, the origin online = service or website sends the Key Handle back to the U2F device=20 via the browser. The U2F device uses the Key Handle to identify the = user's private key, and creates a signature which is sent back=20 to the origin to verify the presence of the U2F device. Thus, the Key = Handle is simply an identifier of a particular key on the U2F device. There is no other registration information needed. Sharing such an = information between RSs does not allow to link user accounts. Denis =20 From: TXAuth = On Behalf Of Denis Sent: Thursday, August 13, 2020 10:31 AM To: txauth@ietf.org =20 Subject: [GNAP] Support of FIDO =20 This topic has already been tackled on the list, but I open a new thread = for it. In OAuth 2.0, one of the goals was to get rid of IDs and passwords. = Since the solution in OAuth 2.0 was to use access tokens,=20 there have been used everywhere, even when they were not strictly = needed.=20 It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS.=20 FIDO should be one allowed possibility for the user authentication. In = the case of FIDO, the user is authenticated under a pseudonym=20 specific to the RS. It may observed that there is no equivalent in OAuth = because of the two different semantics of the subject claim. RFC 7519 states: The "sub" (subject) claim identifies the principal that is the subject = of the JWT. The claims in a JWT are normally statements about the = subject. =20 The subject value MUST either be scoped to be locally unique in the = context of the issuer or be globally unique. In one case, it is possible to link the subject claim of two users = between two RSs (i.e. using a locally unique identifier in the context = of the issuer)=20 while in the other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server=20 (i.e. not supporting OAuth) that is using the same globally unique = identifier. None of these two semantics fit with the FIDO use case where the subject = value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible.=20 There are cases where a user would like to enjoy the unlinkeability = properties of FIDO which cannot be met using the claims currently = defined in OAuth. Denis =20 --=20 TXAuth mailing list TXAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/txauth =20 --=20 Vennlig hilsen =20 Steinar Noem Partner Udelt AS Systemutvikler =20 | steinar@udelt.no | = hei@udelt.no | +47 955 21 620 | www.udelt.no |=20 ------=_NextPart_000_0147_01D6720A.9EE22AF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Correct = U2F is not passwordless like FIDO2 or UAF

 

From: TXAuth = <txauth-bounces@ietf.org> On Behalf Of Steinar = Noem
Sent: Friday, August 14, 2020 6:24 AM
To: Denis = <denis.ietf@free.fr>
Cc: txauth@ietf.org; = nadalin@prodigy.net
Subject: Re: [GNAP] Support of = FIDO

 

Hi = Denis, I have always perceived U2F (which I think has been replaced by = FIDO2/CTAP/WebAuthn) as just a pure second factor and not an = authentication in itself.

I may = be wrong, but from my understanding U2F makes sense in combination with = user authentication, but not as a stand-alone = solution.

 

<mvh>Steinar</mvh>

 

fre. 14. aug. 2020 kl. 12:04 skrev Denis <denis.ietf@free.fr>:=

Hi Tony,

Dennis, not = all the way correct

 <= /o:p>

  • It is also = possible to get rid of IDs and passwords using FIDO. FIDO discloses no = private information at all about the user
    and no trust relationships = need to be defined since there is no AS

Depends on = if you only consider =E2=80=9Cprivate information=E2=80=9D PII, there = can be all sorts of information passed in ClientData field of the FIDO = response, not desirable but perfectly OK

 <= /o:p>

  • None of = these two semantics fit with the FIDO use case where the subject value = is scoped to be locally unique in the context of one RS.
    Hence, the = linkage of users between two RSs (or between one RS and any other = server) becomes impossible

 <= /o:p>

There is = nothing that prohibits the RS from sharing registration information = between RS

I am speaking of FIDO U2F where = there are two main phases: registration and = authentication.

The U2F device gives the public = key and a Key Handle to the origin online service or website during the = user registration step.
Later, when the user performs an = authentication, the origin online service or website sends the Key = Handle back to the U2F device
via the browser. The U2F device uses = the Key Handle to identify the user's private key, and creates a = signature which is sent back
to the origin to verify the presence of = the U2F device. Thus, the Key Handle is simply an identifier of a = particular key on the U2F = device.

There is no other registration = information needed. Sharing such an information between RSs does not = allow to link user accounts.

Denis

 <= /o:p>

From:= TXAuth <txauth-bounces@ietf.org> On Behalf Of = Denis
Sent: Thursday, August 13, 2020 10:31 = AM
To: txauth@ietf.org
Subject: [GNAP] Support = of FIDO

 <= /o:p>

This topic has already been = tackled on the list, but I open a new thread for it.

In OAuth = 2.0, one of the goals was to get rid of IDs and passwords. Since the = solution in OAuth 2.0 was to use access tokens,
there have been used = everywhere, even when they were not strictly needed. =

It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
and no trust relationships need to be defined = since there is no AS.

FIDO should be one allowed = possibility for the user authentication. In the case of FIDO, the user = is authenticated under a pseudonym
specific to the RS. It may = observed that there is no equivalent in OAuth because of the two = different semantics of the subject claim.

RFC 7519 = states:

The "sub" (subject) = claim identifies the principal that is the subject of the JWT.  The = claims in a JWT are normally statements about the subject. 
The = subject value MUST either be scoped to be locally unique in the context = of the issuer or be globally = unique.

In one case, it is possible to = link the subject claim of two users between two RSs (i.e. using a = locally unique identifier in the context of the issuer)
while in the = other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server
(i.e. not supporting OAuth) that is using the same = globally unique identifier.

None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.

Hence, the linkage of users = between two RSs (or between one RS and any other server) becomes = impossible.

There are cases where a user = would like to enjoy the unlinkeability properties of FIDO which cannot = be met using the claims currently defined in = OAuth.

Denis

 

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


 

-- =

Vennlig hilsen

 

Steinar = Noem

Partner Udelt = AS

Systemutvikler

 

| steinar@udelt.no&nb= sp;| hei@udelt.no  | +47 = 955 21 620 | www.udelt.no | 

------=_NextPart_000_0147_01D6720A.9EE22AF0-- From nobody Fri Aug 14 07:17:06 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 7068E3A1142 for ; Fri, 14 Aug 2020 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=prodigy.net 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 vpCtzPb9C2h2 for ; Fri, 14 Aug 2020 07:17:02 -0700 (PDT) Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (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 9FBB13A113B for ; Fri, 14 Aug 2020 07:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597414621; bh=5WW8FRJAIEC9nAGq5SPvPBnTOJphhyMZ8fUTeg0+m/U=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=d7Nc+iN4gYl3yL3KshCeyH+TQaFUUPuFPKt66CNLabcOfDxW7u8q09HwibjIsf3YHJeyM3OehMkaeo/ZHmCIlUH+iZAwVySr26pg3PD3NOy2Y7gcmCF8iM+7c1uv5o0zuZfCjEaYn7+XVzcJuSbZAxnngg1P/awQ2+JAeQ2LTWb9jehPPCI+K5uc98HKAxs1GXJh5XvcOwXLrgiMm5laYijt4VXn9SrGg7ppgEPsbpJcR5vvX/qtAT2PveAv3YLlCHalTYky2dc4R8oaHYaxMTn4y30rg/UqD3c2ZW1DBpyrsADHOGPOmCznCPUmqgF7LWG8I92MnlIfO03oTZEj5w== X-YMail-OSG: 86vqSrAVM1nDU2BXgCU1AMvDVbFmzeqF0n_Fz7QtBnyyV6Sto0EWbLpL5P2uhGM gGzuQPEJd8aoekv68aIsRySisd1lPIMF9qgXQeib.WPNCtG2qHfpZVWFL8MyfW5U7vUMo7crJnO2 9OHFt.gKl7kGi6I8YQM7ewHbxHN_pAB1OoRz0Ig6OwpLdpXbhylKB8Yj212neoQK4pYJggYINhT5 2sPbws78iFSPQ3VzRmbiNvYlaX3gJ8QT9JDd6JgZTanDJ.TenNTvAQqDGKTnxhExvVo5UCOImhLG Qjv2pH2HwK.X4k3nheC_tYjWtaff3VEorfqsAGx83L6.OXLzE.He7gJfcIAI1PSzaqQWg6TXI8zU n.b00AapvhRj0wjAK5UxaoDQVR6mXBl8cdYGHU8tyezefTgDASicsPed64_xCMvVku4EBjjIcGZ. eaDecs_2jJKXLGAczjCMV4uMsbqTKOtP_mEkReX7.i5u2MNWywkzeWj.vhlHVM454tBG_tYVpXFV brttDy1TAd9O7V3HXDeh3Kr6c6T50Tb8Hlt4gXrYyeMnYKnVa6fk7UQDakdFSH_MIUwlEB.4bcXJ HS_7CvCWu_6KWsHfyBZW3muXu4Q3Fd6lsuasNBD_euGe6XfNgemHN8lWsKe4Romg_SPlQlmuF.B. .Gwwh8bSQobDURiXjiH73Ql9FVLQdllAKYBrxfKqVwqQq7AdPftT6pBGYhSvWTagOlsEpKNZBfKk AYrI.Ui.Y0rEwfIT.nb3y8e8STKdqZGoVBUvZTJ8HGp2EJTE6mVB1GE.nxWq.F1pCmwJAgc9Xx0G 4HBofOuwLZOItVXKM723vsriQXiWmlNbBxFWBaaT7cqBZmzGRhkP83L7O4WItv2e3rmhb9.h6tnD 2t1k97sgFCt30KTc3YVE.8njcry4GpuOu8KYFrp0WwPyUB2qzZBtCJumn1Z29Z8fJZOZfZqmBSRk Mo5ZZuy1bmUUohPCJyOZ0XqL69Vl72MDJeNcEVHjVBKN8rOnNC3BpzHxABIv1OsKcJZG6y4s5o3h FAypG7T3kdbv5g98KWUqSVttAylzYTmcJ7z7sgdvkNnMwAoj5BoQswDcA1V0SemUcOwN7UacwOio W0LZs9NlqOsXZ9Rr_i4BI1k6I3fvomcg_VScO5rvms7t3pLofF7u2MWTPfrybnhZF4Db3Mr8qq3x uMDNhaSdCbdrpvylxSE2Yqy0eQIzEtl6cIpoYZSqI6URYUM4KnVnObP7whcTFz1LlD.MZsLLKkJA kpqQU1RI.4K7aiTke_v_yulnTgO25imsijXUsY2Hj3sX37txPVAt92h47vd9cjNVFo0GrlngpJg5 LoogMoken6zlauGCMxwIS5IeDzLi7HzqbYTbOL8RIN7ZOaOLPu8_zFkHHGFchcovbgZudMrvggez dp6gP9W8fCQIZ877APT9mW8tWn8AJlvL4TtjT6gUg613Kz5W5KQ2TLprN7gajTlf.KTn_aQItRmz dCw8b1ymMbYw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 14 Aug 2020 14:17:01 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 39be61271e146f68dc9dfe94d7bb7bd0; Fri, 14 Aug 2020 14:17:00 +0000 (UTC) From: To: "'Denis'" , References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> In-Reply-To: <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> Date: Fri, 14 Aug 2020 07:16:58 -0700 Message-ID: <015801d67245$933b3850$b9b1a8f0$@prodigy.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0159_01D6720A.E6DE0E00" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAJA1Hv+AlIHM6epW+IgIA== Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Fri, 14 Aug 2020 14:17:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0159_01D6720A.E6DE0E00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Not quite Dennis, the U2F device does not store the private key, it only = creates the private key. =20 From: TXAuth On Behalf Of Denis Sent: Friday, August 14, 2020 3:04 AM To: nadalin@prodigy.net; txauth@ietf.org Subject: Re: [GNAP] Support of FIDO =20 Hi Tony,=20 Dennis, not all the way correct =20 * It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D = PII, there can be all sorts of information passed in ClientData field of = the FIDO response, not desirable but perfectly OK =20 * None of these two semantics fit with the FIDO use case where the = subject value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible =20 There is nothing that prohibits the RS from sharing registration = information between RS=20 I am speaking of FIDO U2F where there are two main phases: registration = and authentication. The U2F device gives the public key and a Key Handle to the origin = online service or website during the user registration step.=20 Later, when the user performs an authentication, the origin online = service or website sends the Key Handle back to the U2F device=20 via the browser. The U2F device uses the Key Handle to identify the = user's private key, and creates a signature which is sent back=20 to the origin to verify the presence of the U2F device. Thus, the Key = Handle is simply an identifier of a particular key on the U2F device. There is no other registration information needed. Sharing such an = information between RSs does not allow to link user accounts. Denis =20 From: TXAuth = On Behalf Of Denis Sent: Thursday, August 13, 2020 10:31 AM To: txauth@ietf.org =20 Subject: [GNAP] Support of FIDO =20 This topic has already been tackled on the list, but I open a new thread = for it. In OAuth 2.0, one of the goals was to get rid of IDs and passwords. = Since the solution in OAuth 2.0 was to use access tokens,=20 there have been used everywhere, even when they were not strictly = needed.=20 It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS.=20 FIDO should be one allowed possibility for the user authentication. In = the case of FIDO, the user is authenticated under a pseudonym=20 specific to the RS. It may observed that there is no equivalent in OAuth = because of the two different semantics of the subject claim. RFC 7519 states: The "sub" (subject) claim identifies the principal that is the subject = of the JWT. The claims in a JWT are normally statements about the = subject. =20 The subject value MUST either be scoped to be locally unique in the = context of the issuer or be globally unique. In one case, it is possible to link the subject claim of two users = between two RSs (i.e. using a locally unique identifier in the context = of the issuer)=20 while in the other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server=20 (i.e. not supporting OAuth) that is using the same globally unique = identifier. None of these two semantics fit with the FIDO use case where the subject = value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible.=20 There are cases where a user would like to enjoy the unlinkeability = properties of FIDO which cannot be met using the claims currently = defined in OAuth. Denis =20 ------=_NextPart_000_0159_01D6720A.E6DE0E00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Not quite = Dennis, the U2F device does not store the private key, it only creates = the private key.

 

From: TXAuth = <txauth-bounces@ietf.org> On Behalf Of = Denis
Sent: Friday, August 14, 2020 3:04 AM
To: = nadalin@prodigy.net; txauth@ietf.org
Subject: Re: [GNAP] = Support of FIDO

 

Hi = Tony,

Dennis, not all the way correct

 

  • It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
    and no trust relationships need to be defined = since there is no AS

Depends on if you only consider =E2=80=9Cprivate = information=E2=80=9D PII, there can be all sorts of information passed = in ClientData field of the FIDO response, not desirable but perfectly = OK

 

  • None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.
    Hence, the linkage of users between = two RSs (or between one RS and any other server) becomes = impossible

 

There is = nothing that prohibits the RS from sharing registration information = between RS

I am speaking of FIDO U2F where = there are two main phases: registration and = authentication.

The U2F device gives the public = key and a Key Handle to the origin online service or website during the = user registration step.
Later, when the user performs an = authentication, the origin online service or website sends the Key = Handle back to the U2F device
via the browser. The U2F device uses = the Key Handle to identify the user's private key, and creates a = signature which is sent back
to the origin to verify the presence of = the U2F device. Thus, the Key Handle is simply an identifier of a = particular key on the U2F = device.

There is no other registration = information needed. Sharing such an information between RSs does not = allow to link user accounts.

Denis

 

 

This topic has already been = tackled on the list, but I open a new thread for it.

In OAuth = 2.0, one of the goals was to get rid of IDs and passwords. Since the = solution in OAuth 2.0 was to use access tokens,
there have been used = everywhere, even when they were not strictly needed. =


It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
and no trust relationships need to be defined = since there is no AS.


FIDO should be one allowed = possibility for the user authentication. In the case of FIDO, the user = is authenticated under a pseudonym
specific to the RS. It may = observed that there is no equivalent in OAuth because of the two = different semantics of the subject = claim.


RFC 7519 = states:

The "sub" (subject) = claim identifies the principal that is the subject of the JWT.  The = claims in a JWT are normally statements about the subject. 
The = subject value MUST either be scoped to be locally unique in the context = of the issuer or be globally = unique.

In one case, it is possible to = link the subject claim of two users between two RSs (i.e. using a = locally unique identifier in the context of the issuer)
while in the = other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server
(i.e. not supporting OAuth) that is using the same = globally unique identifier.


None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.

Hence, the linkage of users = between two RSs (or between one RS and any other server) becomes = impossible.


There are cases where a user = would like to enjoy the unlinkeability properties of FIDO which cannot = be met using the claims currently defined in = OAuth.


Denis

 

------=_NextPart_000_0159_01D6720A.E6DE0E00-- From nobody Fri Aug 14 07:28:34 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 53CD73A0C7C for ; Fri, 14 Aug 2020 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mKJaV_t64LbZ for ; Fri, 14 Aug 2020 07:28:30 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C833A0C5E for ; Fri, 14 Aug 2020 07:28:29 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07EESLSA002254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 10:28:22 -0400 From: Justin Richer Message-Id: <305ADCDA-DB5F-47D3-9F8B-25D8E8E6C2CD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_54F77929-EE5C-40DA-8430-654209820622" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 14 Aug 2020 10:28:21 -0400 In-Reply-To: Cc: Dave Tonge , Dick Hardt , Francis Pouatcha , Denis , "txauth@ietf.org" , Benjamin Kaduk To: Fabien Imbault References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Fri, 14 Aug 2020 14:28:32 -0000 --Apple-Mail=_54F77929-EE5C-40DA-8430-654209820622 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the roles are linked, but so are the roles of the AS and RS = (since the RS needs to trust and understand what the AS issues, = ultimately). But by talking about them as separate roles, we can talk = about ways to connect them, much the way that separating the AS from the = RS (which were both just the =E2=80=9Cserver=E2=80=9D in OAuth 1) let us = talk about JWTs and token introspection as methods for connecting the = two. And the thing is, people are already deploying the token-issuing = portions and the interactive portions separately. For example these all = point towards that: https://github.com/ietf-wg-gnap/general/wiki/Decomposed-Grant-Server = = https://github.com/ietf-wg-gnap/general/wiki/Three-Client-server-use-cases= -built-along-%22Privacy-by-Design%22.-Contribution-from-Denis = = https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Server= s-in-a-single-flow = Additionally, this is similar to how Google deploys OAuth 2 today, with = the user interactive portion and the token-issuing portion in separate = trust domains. We can label these parts separately without defining a = single method of connecting them, and importantly without assuming = they=E2=80=99ll be in the same box for someone=E2=80=99s deployment.=20 =E2=80=94 Justin > On Aug 14, 2020, at 2:29 AM, Fabien Imbault = wrote: >=20 > Thanks, that's an important use case. Should add DID also.=20 >=20 > This raises additional questions related to claim aggregation though, = in case you have contradictory information. >=20 > Le ven. 14 ao=C3=BBt 2020 =C3=A0 03:39, Dave Tonge = > a =C3=A9crit = : > > I agree with clearly separating the GS interaction with the Client = from the interaction with the User.=20 >=20 > > I'm having a hard time viewing those as two different roles. They = are two different interactions. Just as the client interaction with the = AS is different from the client interaction with the GS. >=20 > I also struggle to see these as different roles - they seem to be = fundamentally linked,=20 > However what I think does need to be taken into consideration is that = there may be multiple Grant Servers involved in a user flow (I've added = a new use case to describe some of these flows: = https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Server= s-in-a-single-flow = ) >=20 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 --Apple-Mail=_54F77929-EE5C-40DA-8430-654209820622 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the roles are linked, but so are the roles of the AS and RS (since = the RS needs to trust and understand what the AS issues, ultimately). = But by talking about them as separate roles, we can talk about ways to = connect them, much the way that separating the AS from the RS (which = were both just the =E2=80=9Cserver=E2=80=9D in OAuth 1) let us talk = about JWTs and token introspection as methods for connecting the = two.

And the thing = is, people are already deploying the token-issuing portions and the = interactive portions separately. For example these all point towards = that:

https://github.com/ietf-wg-gnap/general/wiki/Decomposed-Grant-S= erver

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-serve= r-use-cases-built-along-%22Privacy-by-Design%22.-Contribution-from-Denis

https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authoriza= tion-Servers-in-a-single-flow


Additionally, this is similar to how Google deploys OAuth 2 = today, with the user interactive portion and the token-issuing portion = in separate trust domains. We can label these parts separately without = defining a single method of connecting them, and importantly without = assuming they=E2=80=99ll be in the same box for someone=E2=80=99s = deployment. 

 =E2=80=94 Justin

On Aug = 14, 2020, at 2:29 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Thanks, that's = an important use case. Should add DID also. 

This raises = additional questions related to claim aggregation though, in case you = have contradictory information.

Le ven. 14 ao=C3=BBt 2020 =C3=A0 03:39, Dave Tonge = <dave.tonge@moneyhub.com> a =C3=A9crit :
> I agree = with clearly separating the GS interaction with the Client from the = interaction with the User. 

> I'm having a hard time viewing those as two different = roles. They are two different interactions. Just as the client = interaction with the AS is different from the client interaction with = the GS.

I also = struggle to see these as different roles - they seem to be fundamentally = linked, 
However what I think does need to be taken into consideration = is that there may be multiple Grant Servers involved in a user flow = (I've added a new use case to describe some of these flows: https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authoriza= tion-Servers-in-a-single-flow)


Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360) at https://register.fca.org.uk/. = Moneyhub Financial Technology is registered in England & Wales, = company registration number 06909772. Moneyhub Financial Technology = Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 = Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is = confidential. Use of this email or of any information in it other than = by the addressee is unauthorised and unlawful. Whilst reasonable efforts = are made to ensure that any attachments are virus-free, it is the = recipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded = for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of = the author and do not necessarily represent the opinions of Moneyhub = Financial Technology Limited or of any other group = company.



= --Apple-Mail=_54F77929-EE5C-40DA-8430-654209820622-- From nobody Fri Aug 14 07:30:53 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 5A8453A1147 for ; Fri, 14 Aug 2020 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gmDtBVWm3fk1 for ; Fri, 14 Aug 2020 07:30:48 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9269A3A113B for ; Fri, 14 Aug 2020 07:30:48 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07EEUd1g003107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 10:30:40 -0400 From: Justin Richer Message-Id: <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B8D1A030-9AAC-432B-9F16-07DCC2E4C872" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 14 Aug 2020 10:30:39 -0400 In-Reply-To: Cc: Denis , Dave Tonge , Francis Pouatcha , Mike Jones , Benjamin Kaduk , Tom Jones , "txauth@ietf.org" , Dick Hardt To: Fabien Imbault References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Terminology 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: Fri, 14 Aug 2020 14:30:51 -0000 --Apple-Mail=_B8D1A030-9AAC-432B-9F16-07DCC2E4C872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps = =E2=80=9C operator=E2=80=9D as the role they play when, you = know, operating the . (Where should still have a more = specific name.) =E2=80=94 Justin > On Aug 14, 2020, at 8:23 AM, Fabien Imbault = wrote: >=20 > Hi Denis,=20 >=20 > Thanks for your feedback.=20 > Comments inline (marked with FI). >=20 > Fabien >=20 > On Fri, Aug 14, 2020 at 12:02 PM Denis > wrote: > Hi Fabien, >=20 > Thank you for your inputs, a ball is finally rolling. >=20 >> An attempt. > I would add upfront: User =3D human person > FI : then end-user is clearer if you want to indicate specifically a = human user. One can also create system users. >> =3D application that requests access to Resource Servers = (RS) through a Grant Server (GS). =20 >> Examples: a web server, a browser-based app, a mobile app, an IoT = device. > A few explanations: "through" does not sound appropriate since it = could be interpreted as the GS being necessarilly placed between the = Client and the RS.=20 > In addition, more than one GS = may be necessary. >=20 > My proposal: =3D application that requests access to = Resource Servers (RS) on behalf of a User by using one or more Grant = Servers (GS)=20 > Examples: a web server, a browser-based app, a mobile app. >=20 > FI: agreed. =20 >=20 >> GS =3D computing service that manages the grant lifecycle to a = on behalf of a Resource Controler (RC). >> Note : for privacy reasons, the GS may be issuing grants without = knowledge of which resources are requested. > I dislike "on behalf of a Resource Controler (RC)". The GS may be = fully ignorant of the existence of the RSs and hence of the RCs. > In addition, "grant life cycle" is undefined. >=20 > My proposal: GS =3D server issuing access tokens to a Client after = successfully authenticating the User > Note 1: for privacy reasons, the GS may be issuing access tokens = without the knowledge of which resources are requested. > Note 2: a GS is able to disclose to a User the User attributes that it = manages. =20 >=20 > FI: I find the new definition less clear. It's not because you don't = know which RS is called that we shouldn't say the decision is made by = the RC.=20 > "grant life cycle" is indeed currently undefined, what i had in mind = is basically the grant flow from the GNAP protocol, possibly also = including revocation etc. > Not sure why Note 2 is important to put here. > =20 >> RS =3D computing service that grants access only if its Resource = Controler (RC) consents. >> Note : the consent may involve a human interaction or may be = automated based on access control policies. > I dislike "its Resource Controler (RC) consents" because it may let = think that a human person always needs to consent. >=20 > My proposal: RS =3D server hosting protected resources, capable of = accepting and responding to protected resource requests=20 > when access tokens are being used > FI : that is why I suggested a note to make sure it is correctly = understood. I'm not sure the proposed alternative is clearer.=20 >=20 >> RC =3D entity which is controlling the access to a protected = resource.=20 >> Note : a RC may be manually operated by a human or delegated to a = machine, partially or completely. > A RC is not an entity but a function. I would also place the machine = case first. >=20 > My proposal: RC =3D function tightly coupled with a RS which controls = the accesses to a protected resource > Note : the function may be operated either by = a machine or by a human person or by some combination of both. >=20 > FI : your proposition on the note makes it much better. On the main = definition, I'm not sure what you mean by function, as a result I'm not = sure a reader would understand. Why do you need to say "tightly = coupled?"=20 >> Consent =3D the process of asking a RC to accept or decline based on = a grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D = or =E2=80=9Cno=E2=80=9D consent decision. > I would instead speak of the "User Consent". The User Consent is a set = of choices among a proposed set of choices. It is not simply a "yes" or = "no" consent decision. >=20 > My proposal: User Consent =3D ability for a User, after being = informed, of choosing to release or not to a RS some attributes = contained in one or more access tokens >=20 >=20 > FI: this may be misleading I think. The consent is done by a RC (or in = OAuth terms, RO), not the application user.=20 > I agree there may be a combination of consent decisions, but I think = it's important to say that in the end for each individual choice, you do = have a yes/no decision.=20 >=20 >=20 > Denis >=20 >=20 >=20 >> Fabien >>=20 >> On Thu, Aug 13, 2020 at 3:55 PM Denis > wrote: >> Fabien, >>=20 >> IMHO, nothing is wrong with keeping "Client" since it has a wide = spread usage >> ... but only as long as we can agree on a short and a clear = definition for it. >>=20 >> I can provide the beginning of such a definition: " application ..." >>=20 >> If someone could go a little bit further, this would help. :-) >>=20 >> A similar argumentation for GS. It could be used but only as long as = we can agree on a short and a clear definition for it. >> Any proposal ? >>=20 >> Denis >>=20 >>> Hi, >>>=20 >>> Nothing inherently wrong with Client/AS, which has worked for years = in the context of OAuth2. The question is to know whether we can build = the new protocol with the same concepts and deal with their known = limitations, or if we're better off with more adapted concepts less = prone to misunderstandings. >>>=20 >>> Verb vs Noun: >>> Problem is that the grant (noun) can only be understood if there is = a grant(verb), i.e. some action that grants something.=20 >>> The grant (noun) definition directly derives from the verb : = "something granted ..." >>>=20 >>> I personally have no issue even with the fairly convoluted "The = Grant Server issues a grant to the Grant Client representing access that = has been granted" (except perhaps from the word Client, but that's a = different issue). >>> By the way, grant is nothing new, it's used extensively in OAuth2 as = "grant types" (whatever that means).=20 >>>=20 >>> Dick summarized well the reasons why he uses GS instead of AS :=20 >>> 1) "grant" is in the working group name (a weaker reason, but still = has been approved). Question: would our reasoning if the protocol ended = up being called OAuth3? >>> 2) grant =3D larger in scope than AS (not only authorization), as it = at least includes idclaims + other use cases like payment (?) - no = consensus, see difference in appreciation between Justin and Dick >>>=20 >>> As for "Client", if most people think it is problematic, it seems a = good reason to change if we find a better alternative.=20 >>> Quoting Dick again: "The confusion in my experience usually stems = from people working with software that is acting in multiple roles. IE, = the software that is acting as a client in once context, is also acting = as an RS in other contexts, or even acting as an AS. The other confusion = is that people view clients as being the software the user is using -- = although it may not be acting as a client in the oauth context." and = later "I do agree that it is not the best term in GNAP. Primarily = because GNAP is a combination of the client from OAuth 2, and the = relying party from OIDC." >>>=20 >>> So far there's no consensus however, recent tries: Initiating = Application (Denis), Orchestrator (Francis).=20 >>>=20 >>> Cheers >>> Fabien >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge > wrote: >>> I would be against using "grant" as both a verb and a noun and stick = purely with one or the other. (In the charter the only use of "grant" is = in the verb: "granted"). >>>=20 >>> Using it as both a verb and a noun will be confusing and less = accessible. >>>=20 >>> I think it will be confusing to say "The Grant Server issues a grant = to the Grant Client representing access that has been granted" >>>=20 >>> Whether the access takes place via a token being returned and used = at a resource server, or "claims" that are directly returned from the = "Grant Server" I think should be largely irrelevant when it comes to the = naming of the roles. >>>=20 >>> In almost all use cases that I have seen the "Grant Server" is = making a policy based decision "to grant" access to requested = resource(s). To me, that is the fundamental operation happening. I think = nearly all use cases can be applied to that, e.g. the GS grants access = to >>> - identity attributes for the end user >>> - verify an identity attribute (e.g. that user is over 18) >>> - all users photos at resource server X >>> - a single photo with id 12345 at resource server Y >>> - resource of type X at any resource server that trusts the Grant = Server >>> - call a payment API with specific properties (e.g. amount < 5) >>> - call a file storage API >>> - call a "contract signing" API with specific properties (e.g. = contract hash of xxx,) >>> =20 >>> While "client" is problematic, it does now have wide spread usage, = so perhaps we are stuck with it.=20 >>> However I agree with Justin and think "Grant Client" makes things = more confusing. >>>=20 >>> What is wrong with keeping "Client" and "Authorization Server"?=20 >>>=20 >>> Dave >>>=20 >>>=20 >>>=20 >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>=20 >>>=20 >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_B8D1A030-9AAC-432B-9F16-07DCC2E4C872 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps = =E2=80=9C<client> operator=E2=80=9D as the role they play when, = you know, operating the <client>. (Where <client> should = still have a more specific name.)

 =E2=80=94 Justin

On Aug = 14, 2020, at 8:23 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, 

Thanks for your feedback. 
Comments = inline (marked with FI).

Fabien

On Fri, Aug 14, 2020 at 12:02 PM Denis = <denis.ietf@free.fr> wrote:
Hi Fabien,

Thank you for your inputs, a ball is = finally rolling.

An = attempt.
I would add = upfront: User =3D  human person
FI : then end-user is clearer if you want to indicate = specifically a human user. One can also create system = users.
<Client> = =3D application that requests access to Resource Servers (RS) through a = Grant Server (GS).  
Examples: = a web server, a browser-based app, a mobile app, an IoT = device.

A few explanations: "through" does not sound appropriate = since it could be interpreted as the GS being necessarilly placed = between the Client and the RS. 
          &nb= sp;             =             &n= bsp; In addition, more than one GS may be = necessary.

My proposal:  <Client> = =3D application that requests access to Resource Servers (RS) on behalf of a User by using one or more = Grant Servers (GS) 
Examples: a web server, a browser-based app, a mobile = app.

FI: = agreed.  

<= blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; = border-left-width: 1px; border-left-style: solid; border-left-color: = rgb(204, 204, 204); padding-left: 1ex;">
GS = =3D computing service that manages the grant lifecycle to a = <Client> on behalf of a Resource Controler (RC).
Note : for privacy reasons, the GS may be issuing grants = without knowledge of which resources are = requested.

I dislike "on behalf of a Resource Controler = (RC)". The GS may be fully ignorant of the existence of the RSs and = hence of the RCs.
In addition, "grant life = cycle" is undefined.

My proposal:  GS =3D server issuing access = tokens to a Client after successfully authenticating the User
Note 1: for privacy reasons, the GS may be = issuing access tokens without the knowledge of which resources are = requested.
Note 2: a GS is able to disclose to a User the = User attributes that it manages.  

FI: I = find the new definition less clear. It's not because you don't know = which RS is called that we shouldn't say the decision is made by the = RC. 
"grant life cycle" is indeed currently = undefined, what i had in mind is basically the grant flow from the GNAP = protocol, possibly also including revocation etc.
Not= sure why Note 2 is important to put here.
 

RS = =3D computing service that grants access only if its Resource Controler = (RC) consents.
Note : the consent may involve a = human interaction or may be automated based on access control = policies.
I dislike = "its Resource Controler (RC) consents" because it may let = think that a human person always needs to consent.

My proposal: RS =3D server hosting protected resources, capable of = accepting and responding to protected resource requests 
          &nb= sp;            = ;           when = access tokens are being used
FI : that is why I suggested a note to make sure it is = correctly understood. I'm not sure the proposed alternative is = clearer. 

RC =3D entity which is controlling the access = to a protected resource. 
Note : a RC may = be manually operated by a human or delegated to a machine, partially or = completely.

A RC is not an entity but a function. I would also place the = machine case first.

My proposal: RC =3D = function tightly coupled with a RS which controls the accesses to a = protected resource
          = ;            &= nbsp; Note : the function may be operated either by a machine or by a = human person or by some combination of = both.

FI : your = proposition on the note makes it much better. On the main definition, = I'm not sure what you mean by function, as a result I'm not sure a = reader would understand. Why do you need to say "tightly = coupled?" 
Consent =3D the process of asking a RC to accept or decline = based on a grant request presentation, resulting in either a =E2=80=9Cyes=E2= =80=9D or =E2=80=9Cno=E2=80=9D consent = decision.

I would instead speak of the "User Consent". The User Consent = is a set of choices among a proposed set of choices. It is not simply a = "yes" or "no" consent decision.

My = proposal: User Consent =3D ability for a User, after being informed, of = choosing to release or not to a RS some attributes contained in one or = more access tokens


FI: this may be = misleading I think. The consent is done by a RC (or in OAuth terms, RO), = not the application user. 
I agree there may = be a combination of consent decisions, but I think it's important to say = that in the end for each individual choice, you do have a yes/no = decision. 


Denis


Fabien

On Thu, Aug = 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr> wrote:
Fabien,

IMHO, nothing is wrong with = keeping "Client" since it has a wide spread usage
... but = only as long as we can agree on a short and a clear definition for = it.

I = can provide the beginning of such a definition: " application = ..."

If= someone could go a little bit further, this would help. = :-)

A = similar argumentation for GS.  It could be used but only as long as we can agree = on a short and a clear definition for it.
Any proposal ?

Denis

Hi,

Nothing inherently wrong with Client/AS, = which has worked for years in the context of OAuth2. The question is to = know whether we can build the new protocol with the same concepts and = deal with their known limitations, or if we're better off with more = adapted concepts less prone to misunderstandings.

Verb vs = Noun:
Problem is that the grant (noun) can only be understood if = there is a grant(verb), i.e. some action that grants = something. 
The grant (noun) definition directly = derives from the verb : "something granted ..."

I personally have = no issue even with the fairly convoluted "The Grant = Server issues a grant to the Grant Client representing access that has = been granted" (except perhaps from the word Client, but that's a = different issue).
By the = way, grant is nothing new, it's used extensively in OAuth2 as "grant = types" (whatever that means). 

Dick summarized well the = reasons why he uses GS instead of AS : 
1) "grant" = is in the working group name (a weaker reason, but still has been = approved). Question: would our reasoning if the protocol ended up being = called OAuth3?
2) grant =3D larger in scope than AS (not only = authorization), as it at least includes idclaims + other use cases = like payment (?) - no consensus, see difference in appreciation between = Justin and Dick

As for "Client", if most = people think it is problematic, it seems a good reason to change if we = find a better alternative. 
Quoting Dick again: = "The confusion in my experience usually stems from people = working with software that is acting in multiple roles. = IE, the software that is acting as a client in once context, is also acting as an RS = in other contexts, or even acting as an AS. The other confusion is that = people view clients as being the = software the user is using -- although it may not be acting as = a client in the oauth context." and = later "I do agree that it is not the best term in GNAP. Primarily = because GNAP is a combination of the client from OAuth 2, and the relying party from = OIDC."

So far there's no consensus = however, recent tries: Initiating Application (Denis), Orchestrator = (Francis). 

Cheers
Fabien




On Thu, Aug = 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I would be against using "grant" as both a = verb and a noun and stick purely with one or the other. (In the charter = the only use of "grant" is in the verb: "granted").

Using it as both a verb and a noun will be confusing and less = accessible.

I think it will be confusing to say "The Grant Server issues = a grant to the Grant Client representing access that has been = granted"

Whether= the access takes place via a token being returned and used at a = resource server, or "claims" that are directly returned from the "Grant = Server" I think should be largely irrelevant when it comes to the naming = of the roles.

In= almost all use cases that I have seen the "Grant Server" is making a = policy based decision "to grant" access to requested resource(s). To me, = that is the fundamental operation happening. I think nearly all use = cases can be applied to that, e.g. the GS grants access to
 - identity attributes for the end user
 - verify an identity attribute (e.g. that user is = over 18)
 - all users photos at resource = server X
 - a single photo with id 12345 at = resource server Y
 - resource of type X at any = resource server that trusts the Grant Server
 - = call a payment API with specific properties (e.g. amount < = 5)
 - call a file storage API
 - call a "contract signing" API with specific = properties (e.g. contract hash of xxx,)
 
While "client" is problematic, it = does now have wide spread usage, so perhaps we are stuck with = it. 
However I agree with = Justin and think "Grant Client" makes things more confusing.

What is wrong with = keeping "Client" and "Authorization Server"? 

Dave




Moneyhub Enterprise is a trading style of = Moneyhub Financial Technology Limited which is authorised and regulated = by the Financial Conduct Authority ("FCA"). Moneyhub Financial = Technology is entered on the Financial Services Register (FRN 809360) = at https://register.fca.org.uk/. Moneyhub Financial = Technology is registered in England & Wales, company registration = number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 = Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 = 6EA. 

DISCLAIMER: = This email (including any attachments) is subject to copyright, and the = information in it is confidential. Use of this email or of any = information in it other than by the addressee is unauthorised and = unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company.




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

= --Apple-Mail=_B8D1A030-9AAC-432B-9F16-07DCC2E4C872-- From nobody Fri Aug 14 08:06:36 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 C08683A0CC1 for ; Fri, 14 Aug 2020 08:06:34 -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 NKdEn3aAptAm for ; Fri, 14 Aug 2020 08:06:32 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 77A373A0CAF for ; Fri, 14 Aug 2020 08:06:31 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id f12so8614979wru.13 for ; Fri, 14 Aug 2020 08:06:31 -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=PGqVJtZvoj4EWXCJQ+rf0Y+F3XS1Nf3bbhbRcifJGDo=; b=hW1UISiIEPAs9lVZ1pdc4GqUrsTv4f7evAL3Mi128VPOzW0XsN6iWTSXdPWt+pv2ty h31qVpibIx+rsLB/lReC8xWujiaRexurpMxLJs8sRmclQbd+vsI4KK936RoGdsXEUae5 a0UONvh/Bg4PnpyLjM6R93wjsMpsq6Mo0kO4E= 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=PGqVJtZvoj4EWXCJQ+rf0Y+F3XS1Nf3bbhbRcifJGDo=; b=A3giG/TUT9Vbo+L4sXaNA1w8S+J4WAhNg8lrUht5nY4S4VWOufVISnR9KAODhA7ZEU CI7u9rli6DRI+pZXsp9rfm9UZJz6mSuP8d5fhQXSiRm3WJw7rLHNjXl+gbgOo6YXd0Sw HjUW0aHK8PQHWhn0N8fgXWdn+J8XWoT4MweQNjJAPqogWqEUiQn/5eJ7+VchNtAcQ0b3 EPK8rwL7fGTidJfPwcAPGFTef5Aag9Mv40zJeEsOYegFEyqgnko3FOG99Ude1IoiVmaD XDhTF/JkIMsc8DgwidzkisCOhCPTJMiOYy5CxpqUGh5JDlnhUEvxYHVGjs1Dkf6VWkty 5LtA== X-Gm-Message-State: AOAM532NPr1u3V5BNc/TupVdVjqKhhLtzUCobX9xLXTNDejkFqriUKab HxEGUNr1MVGXPKvY/iWUZ96/ydaL9wqklp0PkXy8mQ== X-Google-Smtp-Source: ABdhPJwDQv8Qw9iFAYuEoFIOxhPi3Eb5fuB5kIojDKyLfbteFxpqUzkOJYgHX5kJBN46P7uonD38Q9pOPScC9KLsNkQ= X-Received: by 2002:a5d:45c9:: with SMTP id b9mr3022823wrs.283.1597417589543; Fri, 14 Aug 2020 08:06:29 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> In-Reply-To: <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> From: Francis Pouatcha Date: Fri, 14 Aug 2020 11:06:18 -0400 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , Dave Tonge , Mike Jones , Benjamin Kaduk , Tom Jones , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000fba97105acd7c37a" Archived-At: Subject: Re: [GNAP] Terminology - into Github Issues 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: Fri, 14 Aug 2020 15:06:35 -0000 --000000000000fba97105acd7c37a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have been having a lot of great suggestions and discussion in the list on terms. As we go on, a lot of knowledge gets buried in the mailing archives. This why i suggest we use the use cases github wiki to: - start compiling discussions on single terms into issues (tickets), - also create a ticket for each use case, either linking the wiki page, The wiki page will be used to hold the last consolidated state of the definition or use case. Using tickets to complement wiki pages will allow us to: - move valuable contributions on each word or use case to the comment section of the corresponding ticket. - allow contributors or visitors to read the summary of what was discussed on a term (resp. use case) before proceeding with additional comments/questions. - Help focus toward reusable content. What do you think? Best regards /Francis On Fri, Aug 14, 2020 at 10:30 AM Justin Richer wrote: > +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps =E2=80= =9C operator=E2=80=9D as > the role they play when, you know, operating the . (Where > should still have a more specific name.) > > =E2=80=94 Justin > > On Aug 14, 2020, at 8:23 AM, Fabien Imbault > wrote: > > Hi Denis, > > Thanks for your feedback. > Comments inline (marked with FI). > > Fabien > > On Fri, Aug 14, 2020 at 12:02 PM Denis wrote: > >> Hi Fabien, >> >> Thank you for your inputs, a ball is finally rolling. >> >> An attempt. >> >> I would add upfront: User =3D human person >> >> FI : then end-user is clearer if you want to indicate specifically a > human user. One can also create system users. > >> * =3D application that requests access to Resource Servers (RS) >> through a Grant Server (GS). * >> Examples: a web server, a browser-based app, a mobile app, an IoT device= . >> >> A few explanations: "through" does not sound appropriate since it could >> be interpreted as the GS being necessarilly placed between the Client an= d >> the RS. >> In addition, more than one GS may >> be necessary. >> >> My proposal: * =3D application that requests access to Resource >> Servers (RS) **on behalf of a User by using one or more Grant Servers >> (GS) * >> *Examples: a web server, a browser-based app, a mobile app.* >> >> FI: agreed. > >> >> *GS =3D computing service that manages the grant lifecycle to a = on >> behalf of a Resource Controler (RC).* >> Note : for privacy reasons, the GS may be issuing grants without >> knowledge of which resources are requested. >> >> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be >> fully ignorant of the existence of the RSs and hence of the RCs. >> In addition, "*grant life cycle*" is undefined. >> >> My proposal: *GS =3D server issuing access tokens to a Client after >> successfully authenticating the User* >> >> >> *Note 1: for privacy reasons, the GS may be issuing access tokens withou= t >> the knowledge of which resources are requested.Note 2: a GS is able to >> disclose to a User the User attributes that it manages. * >> >> FI: I find the new definition less clear. It's not because you don't kno= w > which RS is called that we shouldn't say the decision is made by the RC. > "grant life cycle" is indeed currently undefined, what i had in mind is > basically the grant flow from the GNAP protocol, possibly also including > revocation etc. > Not sure why Note 2 is important to put here. > > >> *RS =3D computing service that grants access only if its Resource Contro= ler >> (RC) consents.* >> Note : the consent may involve a human interaction or may be automated >> based on access control policies. >> >> I dislike "*its Resource Controler (RC) consents" *because it may let >> think that a human person always needs to consent. >> >> My proposal: *R* >> *S =3D server hosting protected resources, capable of accepting and >> responding to protected resource requests >> when access tokens are being used* >> >> FI : that is why I suggested a note to make sure it is correctly > understood. I'm not sure the proposed alternative is clearer. > >> >> *RC =3D entity which is controlling the access to a protected resource. = * >> Note : a RC may be manually operated by a human or delegated to a >> machine, partially or completely. >> >> A RC is not an entity but a function. I would also place the machine cas= e >> first. >> >> My proposal: >> *RC =3D function tightly coupled with a RS which controls the accesses t= o a >> protected resource* Note : the function may be >> operated either by a machine or by a human person or by some combination= of >> both. >> >> FI : your proposition on the note makes it much better. On the main > definition, I'm not sure what you mean by function, as a result I'm not > sure a reader would understand. Why do you need to say "tightly coupled?" > >> *Consent =3D the process of asking a RC to accept or decline based on a >> grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D = or =E2=80=9Cno=E2=80=9D consent >> decision.* >> >> I would instead speak of the "User Consent". The User Consent is a set o= f >> choices among a proposed set of choices. It is not simply a "yes" or "no= " >> consent decision. >> >> My proposal: *User Consent =3D ability for a User, after being informed, >> of choosing to release or not to a RS some attributes contained in one o= r >> more access tokens* >> >> > FI: this may be misleading I think. The consent is done by a RC (or in > OAuth terms, RO), not the application user. > I agree there may be a combination of consent decisions, but I think it's > important to say that in the end for each individual choice, you do have = a > yes/no decision. > >> >> Denis >> >> >> Fabien >> >> On Thu, Aug 13, 2020 at 3:55 PM Denis wrote: >> >>> Fabien, >>> >>> IMHO, nothing is wrong with keeping "Client" since it has a wide spread >>> usage >>> ... but only as long as we can agree on a short and a clear definition >>> for it. >>> >>> I can provide the beginning of such a definition: " application ..." >>> >>> If someone could go a little bit further, this would help. :-) >>> >>> A similar argumentation for GS. It could be used but only as long as >>> we can agree on a short and a clear definition for it. >>> Any proposal ? >>> >>> Denis >>> >>> Hi, >>> >>> Nothing inherently wrong with Client/AS, which has worked for years in >>> the context of OAuth2. The question is to know whether we can build the= new >>> protocol with the same concepts and deal with their known limitations, = or >>> if we're better off with more adapted concepts less prone to >>> misunderstandings. >>> >>> Verb vs Noun: >>> Problem is that the grant (noun) can only be understood if there is a >>> grant(verb), i.e. some action that grants something. >>> The grant (noun) definition directly derives from the verb : "something >>> granted ..." >>> >>> I personally have no issue even with the fairly convoluted "The Grant >>> Server issues a grant to the Grant Client representing access that has = been >>> granted" (except perhaps from the word Client, but that's a different >>> issue). >>> By the way, grant is nothing new, it's used extensively in OAuth2 as >>> "grant types" (whatever that means). >>> >>> Dick summarized well the reasons why he uses GS instead of AS : >>> 1) "grant" is in the working group name (a weaker reason, but still has >>> been approved). Question: would our reasoning if the protocol ended up >>> being called OAuth3? >>> 2) grant =3D larger in scope than AS (not only authorization), as it at >>> least includes idclaims + other use cases like payment (?) - no consens= us, >>> see difference in appreciation between Justin and Dick >>> >>> As for "Client", if most people think it is problematic, it seems a goo= d >>> reason to change if we find a better alternative. >>> Quoting Dick again: "The confusion in my experience usually stems from >>> people working with software that is acting in multiple roles. IE, the >>> software that is acting as a client in once context, is also acting as >>> an RS in other contexts, or even acting as an AS. The other confusion i= s >>> that people view clients as being the software the user is using -- >>> although it may not be acting as a client in the oauth context." and >>> later "I do agree that it is not the best term in GNAP. Primarily becau= se >>> GNAP is a combination of the client from OAuth 2, and the relying party >>> from OIDC." >>> >>> So far there's no consensus however, recent tries: Initiating >>> Application (Denis), Orchestrator (Francis). >>> >>> Cheers >>> Fabien >>> >>> >>> >>> >>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >>> wrote: >>> >>>> I would be against using "grant" as both a verb and a noun and stick >>>> purely with one or the other. (In the charter the only use of "grant" = is in >>>> the verb: "granted"). >>>> >>>> Using it as both a verb and a noun will be confusing and less >>>> accessible. >>>> >>>> I think it will be confusing to say "The Grant Server issues a grant t= o >>>> the Grant Client representing access that has been granted" >>>> >>>> Whether the access takes place via a token being returned and used at = a >>>> resource server, or "claims" that are directly returned from the "Gran= t >>>> Server" I think should be largely irrelevant when it comes to the nami= ng of >>>> the roles. >>>> >>>> In almost all use cases that I have seen the "Grant Server" is making = a >>>> policy based decision "to grant" access to requested resource(s). To m= e, >>>> that is the fundamental operation happening. I think nearly all use ca= ses >>>> can be applied to that, e.g. the GS grants access to >>>> - identity attributes for the end user >>>> - verify an identity attribute (e.g. that user is over 18) >>>> - all users photos at resource server X >>>> - a single photo with id 12345 at resource server Y >>>> - resource of type X at any resource server that trusts the Grant >>>> Server >>>> - call a payment API with specific properties (e.g. amount < 5) >>>> - call a file storage API >>>> - call a "contract signing" API with specific properties (e.g. >>>> contract hash of xxx,) >>>> >>>> While "client" is problematic, it does now have wide spread usage, so >>>> perhaps we are stuck with it. >>>> However I agree with Justin and think "Grant Client" makes things more >>>> confusing. >>>> >>>> What is wrong with keeping "Client" and "Authorization Server"? >>>> >>>> Dave >>>> >>>> >>>> >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000fba97105acd7c37a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have been having a lot of great suggestions and di= scussion in the list on terms. As we go on, a lot of knowledge gets buried= =C2=A0in the mailing archives. This why i suggest we use the use cases gith= ub wiki to:

- start compiling discussions on singl= e terms into issues (tickets),
- also create a ticket for each us= e case, either linking the wiki page,

The wiki pag= e will be used to hold the last consolidated=C2=A0state of the definition o= r use case.

Using tickets to complement wiki pages= will allow us to:
- move valuable contributions on each word or = use case to the comment section of the corresponding ticket.
- al= low contributors or visitors to read the summary=C2=A0of what was discussed= on a term (resp. use case) before proceeding with additional comments/ques= tions.
- Help focus=C2=A0toward reusable content.

<= /div>
What do you=C2=A0think?

Best regards
/Francis

On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <jricher@mit.edu> wrote:
+1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhap= s =E2=80=9C<client> operator=E2=80=9D as the role they play when, you= know, operating the <client>. (Where <client> should still hav= e a more specific name.)

=C2=A0=E2=80=94 Justin
=
On Aug 14, 2020, at 8:23 AM, Fabien Imba= ult <fabie= n.imbault@gmail.com> wrote:

Hi Denis,=C2=A0

Thanks for your feedba= ck.=C2=A0
Comments inline (marked with FI).

<= div>Fabien

On Fri, Aug 14, 2020 at 12:02 PM Denis <denis.ietf@free.fr> wrote:
Hi Fabien,

Thank you for your inputs, a ball is finally rolling= .

An at= tempt.
I would add upfront: User =3D=C2= =A0 human person
FI : then end-user is = clearer if you want to indicate specifically a human user. One can also cre= ate system users.
<Client> = =3D application that requests access to Resource Servers (RS) through a Gra= nt Server (GS).=C2=A0=C2=A0
Examples: a=C2=A0web server, a br= owser-based app, a mobile app, an IoT device.

A few explanations: "through" does not sound appr= opriate since it could be interpreted as the GS being necessarilly placed b= etween the Client and the RS.=C2=A0
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 In addition, more than one GS may be necessary.


GS = =3D computing service that manages the grant lifecycle=C2=A0to a <Client= > on behalf of a Resource Controler (RC).
Note : for priva= cy reasons, the GS may be issuing grants without knowledge of which resourc= es are requested.

I dislike &q= uot;on behalf of a Resource Controler (RC)". The GS may be full= y ignorant of the existence of the RSs and hence of the RCs.
In addition= , "grant life cycle" is undefined.

My pro= posal:=C2=A0=C2=A0GS =3D=C2=A0server is= suing access tokens to a Client after successfully authenticating the User<= /i>
Note 1: for privacy reasons, the GS may be issuing access tokens = without the knowledge of which resources are requested.
Note 2: a GS is = able to disclose to a User the User attributes that it manages.=C2=A0= =C2=A0

FI: I find th= e new definition less clear. It's not because you don't know which = RS is called that we shouldn't say the decision is made by the RC.=C2= =A0
"grant life cycle" is indeed currently undefined, w= hat i had in mind is basically the grant flow from the GNAP protocol, possi= bly also including revocation etc.
Not sure why Note 2 is importa= nt to put here.
=C2=A0

RS =3D computing service that grant= s access only if its Resource Controler (RC) consents.
Note := the consent may involve a human interaction or may be automated based on a= ccess control policies.
I dislike= "its Resource Controler (RC) consents"=C2=A0= because it may let think that a human person always needs to consent.
My proposal:=C2=A0RS =3D server hosting protected = resources, capable of accepting and responding to protected resource reques= ts=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= when access tokens are being used
= FI : that is why I suggested a note to make sure it is correctly understood= . I'm not sure the proposed alternative is clearer.=C2=A0

RC =3D entity whic= h is controlling the access to a protected resource.=C2=A0
No= te : a RC may be manually operated by a human or delegated to a machine, pa= rtially or completely.

A RC is= not an entity but a function. I would also place the machine case first.

My proposal:=C2=A0RC =3D function tightly coupled with= a RS which controls the accesses to a protected resource
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note : the function = may be operated either by a machine or by a human person or by some combina= tion of both.

FI : your proposition= on the note makes it much better. On the main definition, I'm not sure= what you mean by function, as a result I'm not sure a reader would und= erstand. Why do you need to say "tightly coupled?"=C2=A0
Consent =3D the p= rocess of asking a RC to accept or decline based on a grant request present= ation, resulting in either a =E2=80=9Cyes=E2=80=9D or =E2=80=9Cno=E2=80=9D = consent decision.

I would = instead speak of the "User Consent". The User Consent is a set of= choices among a proposed set of choices. It is not simply a "yes"= ; or "no" consent decision.

My proposal:=C2=A0User Consent =3D ability for a User, after being informed, of choosi= ng to release or not to a RS some attributes contained in one or more acces= s tokens


FI: thi= s may be misleading I think. The consent is done by a RC (or in OAuth terms= , RO), not the application user.=C2=A0
I agree there may be a com= bination of consent decisions, but I think it's important to say that i= n the end for each individual choice, you do have a yes/no decision.=C2=A0<= /div>

=

Denis


Fabien

On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr= > wrote:
Fabien,
IMHO, nothing is wrong with k= eeping "Client" since it has a wide spread usage
... but only = as long as we can agree on a short and a clear definition for it.

I c= an provide the beginning of such a definition: " application ..."=

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.=C2=A0 It could be used but=C2=A0only as long as we can = agree on a short and a clear definition for it.
Any proposal ?

Denis

Hi,=

Noth= ing inherently wrong with Client/AS, which has worked for years in the cont= ext of OAuth2. The question is to know whether we can build the new protoco= l with the same concepts and deal with their known limitations, or if we= 9;re better off with more adapted concepts less prone to misunderstandings.=

Verb vs Noun:
Problem is that t= he grant (noun) can only be understood if there is a grant(verb), i.e. some= action that grants something.=C2=A0
The grant (noun) definition direct= ly derives from the verb : "something granted ..."

I personally=C2=A0have no issue even with the fairly convoluted &q= uot;The Grant Server issues a grant to the Grant Client representing = access that has been granted" (except perhaps from the word Client, bu= t that's a different issue).
By the way, grant i= s nothing new, it's used extensively in OAuth2 as "grant types&quo= t; (whatever that means).=C2=A0

Dick summarized well the reasons = why he uses GS instead of AS :=C2=A0
1) "grant" is in the working group name (a wea= ker reason, but still has been approved). Question: would our reasoning if = the protocol ended up being called OAuth3?
2) grant =3D larger in scope than AS (not only aut= horization), as it at least includes idclaims=C2=A0+ other use cases like p= ayment (?) - no consensus, see difference in appreciation between Justin an= d Dick

=
As for "Client"= ;, if most people think it is problematic, it seems a good reason to change= if we find a better alternative.=C2=A0
Quoting Dick again: "The confusion in my = experience usually stems from people working=C2=A0with software=C2=A0that i= s acting in multiple=C2=A0roles. IE, the software=C2=A0that is acting as a= =C2=A0client=C2=A0in once context, is also acting as an RS in = other contexts, or even acting as an AS. The other confusion is that people= view=C2=A0clients=C2=A0as being the software the user is usin= g -- although it may not be acting as a=C2=A0client=C2=A0in th= e oauth context." and later "I do agree that it is not the best t= erm in GNAP. Primarily because GNAP is a combination of the=C2=A0clie= nt=C2=A0from OAuth 2, and the relying party from OIDC."

So far there's no consensus however, rece= nt tries: Initiating Application (Denis), Orchestrator (Francis).=C2=A0

Cheers=
Fabien




On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> = wrote:
I would be against using "gra= nt" as both a verb and a noun and stick purely with one or the other. = (In the charter the only use of "grant" is in the verb: "gra= nted").

Using it as both a verb and a nou= n will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a gran= t to the Grant Client representing access that has been granted"
=

Whether the access takes place via a token being return= ed and used at a resource server, or "claims" that are directly r= eturned from the "Grant Server" I think should be largely irrelev= ant when it comes to the naming of the roles.

In a= lmost all use cases that I have seen the "Grant Server" is making= a policy based decision "to grant" access to requested resource(= s). To me, that is the fundamental operation happening. I think nearly all = use cases can be applied to that, e.g. the GS grants access to
= =C2=A0- identity=C2=A0attributes for the end user
=C2=A0- verify= =C2=A0an identity attribute (e.g. that user is over 18)
=C2=A0- a= ll users photos at resource server X
=C2=A0- a single photo with = id 12345 at resource server Y
=C2=A0- resource of type X at any r= esource server that trusts the Grant Server
=C2=A0- call a paymen= t API with specific properties (e.g. amount < 5)
=C2=A0- call = a file storage API
=C2=A0- call a "contract signing" AP= I with specific properties (e.g. contract hash of xxx,)
=C2=A0
While "client" is problematic, it does now have wide spre= ad usage, so perhaps we are stuck with it.=C2=A0
However I ag= ree with Justin and think "Grant Client" makes things more confus= ing.

What is wrong with keeping "Client"= and "Authorization Server"?=C2=A0

Dave<= /div>




Moneyhub Enterprise is a trading style of Moneyhub Financial Techno= logy Limited which is authorised and regulated by the Financial Conduct Aut= hority ("FCA"). Moneyhub Financial Technology is entered on the F= inancial Services Register (FRN 809360) at=C2=A0https://register.fca.org= .uk/. Moneyhub Financial Technology is registered in England &am= p; Wales, company registration number 06909772. Moneyhub Financial Technolo= gy Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 = Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (including any attachments) = is subject to copyright, and the information in it is confidential. Use of = this email or of any information in it other than by the addressee is unaut= horised and unlawful. Whilst reasonable efforts are made to ensure that any= attachments are virus-free, it is the recipient's sole responsibility = to scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating to t= his company's business. Any opinions expressed in this email (or in any= attachments) are those of the author and do not necessarily represent the = opinions of Moneyhub Financial Technology Limited or of any other group com= pany.




--=C2=A0
= TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/txauth



--
<= div>
Francis Pouatcha
=
Co-Founder and Technical Lead
--000000000000fba97105acd7c37a-- From nobody Fri Aug 14 08:33:54 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 B1F623A07AB for ; Fri, 14 Aug 2020 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LRME8KV6sh1I for ; Fri, 14 Aug 2020 08:33:49 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55E93A0E46 for ; Fri, 14 Aug 2020 08:33:48 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d25 with ME id FTZl230022bcEcA03TZlqU; Fri, 14 Aug 2020 17:33:46 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 17:33:46 +0200 X-ME-IP: 90.79.51.120 To: Francis Pouatcha Cc: "txauth@ietf.org" References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> From: Denis Message-ID: Date: Fri, 14 Aug 2020 17:33:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A150B5871AB9E21F606EA9D7" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology - into Github Issues 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: Fri, 14 Aug 2020 15:33:53 -0000 This is a multi-part message in MIME format. --------------A150B5871AB9E21F606EA9D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Francis, - 1. The mailing list is the usual way to exchange short information. The use of the wiki should be restricted to long contributions. You are invited to contribute on the mailing list by proposing both a wording and its meaning if a current proposed wording does not meet your expectations and whenever possible with a short rational. Denis > We have been having a lot of great suggestions and discussion in the > list on terms. As we go on, a lot of knowledge gets buried in the > mailing archives. This why i suggest we use the use cases github wiki to: > > - start compiling discussions on single terms into issues (tickets), > - also create a ticket for each use case, either linking the wiki page, > > The wiki page will be used to hold the last consolidated state of the > definition or use case. > > Using tickets to complement wiki pages will allow us to: > - move valuable contributions on each word or use case to the comment > section of the corresponding ticket. > - allow contributors or visitors to read the summary of what was > discussed on a term (resp. use case) before proceeding with additional > comments/questions. > - Help focus toward reusable content. > > What do you think? > > Best regards > /Francis > > On Fri, Aug 14, 2020 at 10:30 AM Justin Richer > wrote: > > +1 for “end user” as the human person, and perhaps “ > operator” as the role they play when, you know, operating the > . (Where should still have a more specific name.) > >  — Justin > >> On Aug 14, 2020, at 8:23 AM, Fabien Imbault >> > wrote: >> >> Hi Denis, >> >> Thanks for your feedback. >> Comments inline (marked with FI). >> >> Fabien >> >> On Fri, Aug 14, 2020 at 12:02 PM Denis > > wrote: >> >> Hi Fabien, >> >> Thank you for your inputs, a ball is finally rolling. >> >>> An attempt. >> >> I would add upfront: User = human person >> >> FI : then end-user is clearer if you want to indicate >> specifically a human user. One can also create system users. >> >>> / = application that requests access to Resource >>> Servers (RS) through a Grant Server (GS). / >>> Examples: a web server, a browser-based app, a mobile app, >>> an IoT device. >> >> A few explanations: "through" does not sound appropriate >> since it could be interpreted as the GS being >> necessarilly placed between the Client and the RS. >> In addition, more than one GS may be necessary. >> >> My proposal: / = application that requests access >> to Resource Servers (RS)///on behalf of a User/by using >> one or more Grant Servers (GS)/ >> /Examples: a web server, a browser-based app, a mobile app./ >> >> FI: agreed. >> >> >>> /GS = computing service that manages the grant lifecycle to >>> a on behalf of a Resource Controler (RC)./ >>> Note : for privacy reasons, the GS may be issuing grants >>> without knowledge of which resources are requested. >> >> I dislike "/on behalf of a Resource Controler (RC)/". The >> GS may be fully ignorant of the existence of the RSs and >> hence of the RCs. >> In addition, "/grant life cycle/" is undefined./ >> / >> >> My proposal: //GS =/server issuing access tokens to a >> Client after successfully authenticating the User/ >> /Note 1: for privacy reasons, the GS may be issuing >> access tokens without the knowledge of which resources >> are requested. >> Note 2: a GS is able to disclose to a User the User >> attributes that it manages. >> / >> >> FI: I find the new definition less clear. It's not because you >> don't know which RS is called that we shouldn't say the decision >> is made by the RC. >> "grant life cycle" is indeed currently undefined, what i had in >> mind is basically the grant flow from the GNAP protocol, possibly >> also including revocation etc. >> Not sure why Note 2 is important to put here. >> >>> /RS = computing service that grants access only if its >>> Resource Controler (RC) consents./ >>> Note : the consent may involve a human interaction or may be >>> automated based on access control policies. >> >> I dislike "/its Resource Controler (RC) consents"/because >> it may let think that a human person always needs to consent. >> >> My proposal:/R//S = server hosting protected resources, >> capable of accepting and responding to protected resource >> requests >>                                   when access tokens are >> being used/ >> >> FI : that is why I suggested a note to make sure it is correctly >> understood. I'm not sure the proposed alternative is clearer. >> >> >>> /RC = entity which is controlling the access to a protected >>> resource. / >>> Note : a RC may be manually operated by a human or delegated >>> to a machine, partially or completely. >> >> A RC is not an entity but a function. I would also place >> the machine case first. >> >> My proposal:/RC = function tightly coupled with a RS >> which controls the accesses to a protected resource >> /                        Note : the function may be >> operated either by a machine or by a human person or by >> some combination of both. >> >> FI : your proposition on the note makes it much better. On the >> main definition, I'm not sure what you mean by function, as a >> result I'm not sure a reader would understand. Why do you need to >> say "tightly coupled?" >> >>> /Consent = the process of asking a RC to accept or decline >>> based on a grant request presentation, resulting in either a >>> “yes” or “no” consent decision./ >> >> I would instead speak of the "User Consent". The User >> Consent is a set of choices among a proposed set of >> choices. It is not simply a "yes" or "no" consent decision. >> >> My proposal:/User Consent = ability for a User, after >> being informed, of choosing to release or not to a RS >> some attributes contained in one or more access tokens/ >> >> >> FI: this may be misleading I think. The consent is done by a RC >> (or in OAuth terms, RO), not the application user. >> I agree there may be a combination of consent decisions, but I >> think it's important to say that in the end for each individual >> choice, you do have a yes/no decision. >> >> >> Denis >> >> >>> Fabien >>> >>> On Thu, Aug 13, 2020 at 3:55 PM Denis >> > wrote: >>> >>> Fabien, >>> >>> IMHO, nothing is wrong with keeping "Client" since it >>> has a wide spread usage >>> ... but only as long as we can agree on a short and a >>> clear definition for it. >>> >>> I can provide the beginning of such a definition: " >>> application ..." >>> >>> If someone could go a little bit further, this would >>> help. :-) >>> >>> A similar argumentation for GS.  It could be used >>> butonly as long as we can agree on a short and a clear >>> definition for it. >>> Any proposal ? >>> >>> Denis >>> >>>> Hi, >>>> >>>> Nothing inherently wrong with Client/AS, which has >>>> worked for years in the context of OAuth2. The question >>>> is to know whether we can build the new protocol with >>>> the same concepts and deal with their known >>>> limitations, or if we're better off with more adapted >>>> concepts less prone to misunderstandings. >>>> >>>> Verb vs Noun: >>>> Problem is that the grant (noun) can only be understood >>>> if there is a grant(verb), i.e. some action that grants >>>> something. >>>> The grant (noun) definition directly derives from the >>>> verb : "something granted ..." >>>> >>>> I personally have no issue even with the fairly >>>> convoluted "The Grant Server issues a grant to the >>>> Grant Client representing access that has been granted" >>>> (except perhaps from the word Client, but that's a >>>> different issue). >>>> By the way, grant is nothing new, it's used extensively >>>> in OAuth2 as "grant types" (whatever that means). >>>> >>>> Dick summarized well the reasons why he uses GS instead >>>> of AS : >>>> 1) "grant" is in the working group name (a weaker >>>> reason, but still has been approved). Question: would >>>> our reasoning if the protocol ended up being called OAuth3? >>>> 2) grant = larger in scope than AS (not only >>>> authorization), as it at least includes idclaims + >>>> other use cases like payment (?) - no consensus, see >>>> difference in appreciation between Justin and Dick >>>> >>>> As for "Client", if most people think it is >>>> problematic, it seems a good reason to change if we >>>> find a better alternative. >>>> Quoting Dick again: "The confusion in my experience >>>> usually stems from people working with software that is >>>> acting in multiple roles. IE, the software that is >>>> acting as a client in once context, is also acting as >>>> an RS in other contexts, or even acting as an AS. The >>>> other confusion is that people view clients as being >>>> the software the user is using -- although it may not >>>> be acting as a client in the oauth context." and later >>>> "I do agree that it is not the best term in GNAP. >>>> Primarily because GNAP is a combination of the >>>> client from OAuth 2, and the relying party from OIDC." >>>> >>>> So far there's no consensus however, recent tries: >>>> Initiating Application (Denis), Orchestrator (Francis). >>>> >>>> Cheers >>>> Fabien >>>> >>>> >>>> >>>> >>>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >>>> >>> > wrote: >>>> >>>> I would be against using "grant" as both a verb and >>>> a noun and stick purely with one or the other. (In >>>> the charter the only use of "grant" is in the verb: >>>> "granted"). >>>> >>>> Using it as both a verb and a noun will be >>>> confusing and less accessible. >>>> >>>> I think it will be confusing to say "The Grant >>>> Server issues a grant to the Grant Client >>>> representing access that has been granted" >>>> >>>> Whether the access takes place via a token being >>>> returned and used at a resource server, or "claims" >>>> that are directly returned from the "Grant Server" >>>> I think should be largely irrelevant when it comes >>>> to the naming of the roles. >>>> >>>> In almost all use cases that I have seen the "Grant >>>> Server" is making a policy based decision "to >>>> grant" access to requested resource(s). To me, that >>>> is the fundamental operation happening. I think >>>> nearly all use cases can be applied to that, e.g. >>>> the GS grants access to >>>>  - identity attributes for the end user >>>>  - verify an identity attribute (e.g. that user is >>>> over 18) >>>>  - all users photos at resource server X >>>>  - a single photo with id 12345 at resource server Y >>>>  - resource of type X at any resource server that >>>> trusts the Grant Server >>>>  - call a payment API with specific properties >>>> (e.g. amount < 5) >>>>  - call a file storage API >>>>  - call a "contract signing" API with specific >>>> properties (e.g. contract hash of xxx,) >>>> While "client" is problematic, it does now have >>>> wide spread usage, so perhaps we are stuck with it. >>>> However I agree with Justin and think "Grant >>>> Client" makes things more confusing. >>>> >>>> What is wrong with keeping "Client" and >>>> "Authorization Server"? >>>> >>>> Dave >>>> >>>> >>>> >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub >>>> Financial Technology Limited which is authorised >>>> and regulated by the Financial Conduct Authority >>>> ("FCA"). Moneyhub Financial Technology is entered >>>> on the Financial Services Register (FRN 809360) >>>> athttps://register.fca.org.uk/. Moneyhub Financial >>>> Technology is registered in England & Wales, >>>> company registration number 06909772. Moneyhub >>>> Financial Technology Limited 2020 © Moneyhub >>>> Enterprise, Regus Building, Temple Quay, 1 Friary, >>>> Bristol, BS1 6EA. >>>> >>>> DISCLAIMER: This email (including any attachments) >>>> is subject to copyright, and the information in it >>>> is confidential. Use of this email or of any >>>> information in it other than by the addressee is >>>> unauthorised and unlawful. Whilst reasonable >>>> efforts are made to ensure that any attachments are >>>> virus-free, it is the recipient's sole >>>> responsibility to scan all attachments for viruses. >>>> All calls and emails to and from this company may >>>> be monitored and recorded for legitimate purposes >>>> relating to this company's business. Any opinions >>>> expressed in this email (or in any attachments) are >>>> those of the author and do not necessarily >>>> represent the opinions of Moneyhub Financial >>>> Technology Limited or of any other group company. >>>> >>>> >>> >> >> -- >> 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/ --------------A150B5871AB9E21F606EA9D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Francis,

- 1.

The mailing list is the usual way to exchange short information. The use of the wiki should be restricted to long contributions.
You are invited to contribute on the mailing list by proposing both a wording and its meaning if a current proposed wording
does not meet your expectations and whenever possible with a short rational.

Denis

We have been having a lot of great suggestions and discussion in the list on terms. As we go on, a lot of knowledge gets buried in the mailing archives. This why i suggest we use the use cases github wiki to:

- start compiling discussions on single terms into issues (tickets),
- also create a ticket for each use case, either linking the wiki page,

The wiki page will be used to hold the last consolidated state of the definition or use case.

Using tickets to complement wiki pages will allow us to:
- move valuable contributions on each word or use case to the comment section of the corresponding ticket.
- allow contributors or visitors to read the summary of what was discussed on a term (resp. use case) before proceeding with additional comments/questions.
- Help focus toward reusable content.

What do you think?

Best regards
/Francis

On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <jricher@mit.edu> wrote:
+1 for “end user” as the human person, and perhaps “<client> operator” as the role they play when, you know, operating the <client>. (Where <client> should still have a more specific name.)

 — Justin

On Aug 14, 2020, at 8:23 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Denis, 

Thanks for your feedback. 
Comments inline (marked with FI).

Fabien

On Fri, Aug 14, 2020 at 12:02 PM Denis <denis.ietf@free.fr> wrote:
Hi Fabien,

Thank you for your inputs, a ball is finally rolling.

An attempt.
I would add upfront: User =  human person
FI : then end-user is clearer if you want to indicate specifically a human user. One can also create system users.
<Client> = application that requests access to Resource Servers (RS) through a Grant Server (GS).  
Examples: a web server, a browser-based app, a mobile app, an IoT device.

A few explanations: "through" does not sound appropriate since it could be interpreted as the GS being necessarilly placed between the Client and the RS. 
                                      In addition, more than one GS may be necessary.

My proposal:  <Client> = application that requests access to Resource Servers (RS) on behalf of a User by using one or more Grant Servers (GS) 
Examples: a web server, a browser-based app, a mobile app.

FI: agreed.  

GS = computing service that manages the grant lifecycle to a <Client> on behalf of a Resource Controler (RC).
Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested.

I dislike "on behalf of a Resource Controler (RC)". The GS may be fully ignorant of the existence of the RSs and hence of the RCs.
In addition, "grant life cycle" is undefined.

My proposal:  GS = server issuing access tokens to a Client after successfully authenticating the User
Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested.
Note 2: a GS is able to disclose to a User the User attributes that it manages.  

FI: I find the new definition less clear. It's not because you don't know which RS is called that we shouldn't say the decision is made by the RC. 
"grant life cycle" is indeed currently undefined, what i had in mind is basically the grant flow from the GNAP protocol, possibly also including revocation etc.
Not sure why Note 2 is important to put here.
 
RS = computing service that grants access only if its Resource Controler (RC) consents.
Note : the consent may involve a human interaction or may be automated based on access control policies.
I dislike "its Resource Controler (RC) consents" because it may let think that a human person always needs to consent.

My proposal: RS = server hosting protected resources, capable of accepting and responding to protected resource requests 
                                  when access tokens are being used
FI : that is why I suggested a note to make sure it is correctly understood. I'm not sure the proposed alternative is clearer. 

RC = entity which is controlling the access to a protected resource. 
Note : a RC may be manually operated by a human or delegated to a machine, partially or completely.

A RC is not an entity but a function. I would also place the machine case first.

My proposal: RC = function tightly coupled with a RS which controls the accesses to a protected resource
                        Note : the function may be operated either by a machine or by a human person or by some combination of both.

FI : your proposition on the note makes it much better. On the main definition, I'm not sure what you mean by function, as a result I'm not sure a reader would understand. Why do you need to say "tightly coupled?" 
Consent = the process of asking a RC to accept or decline based on a grant request presentation, resulting in either a “yes” or “no” consent decision.

I would instead speak of the "User Consent". The User Consent is a set of choices among a proposed set of choices. It is not simply a "yes" or "no" consent decision.

My proposal: User Consent = ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens


FI: this may be misleading I think. The consent is done by a RC (or in OAuth terms, RO), not the application user. 
I agree there may be a combination of consent decisions, but I think it's important to say that in the end for each individual choice, you do have a yes/no decision. 


Denis


Fabien

On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr> wrote:
Fabien,

IMHO, nothing is wrong with keeping "Client" since it has a wide spread usage
... but only as long as we can agree on a short and a clear definition for it.

I can provide the beginning of such a definition: " application ..."

If someone could go a little bit further, this would help. :-)

A similar argumentation for GS.  It could be used but only as long as we can agree on a short and a clear definition for it.
Any proposal ?

Denis

Hi,

Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings.

Verb vs Noun:
Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something. 
The grant (noun) definition directly derives from the verb : "something granted ..."

I personally have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perhaps from the word Client, but that's a different issue).
By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types" (whatever that means). 

Dick summarized well the reasons why he uses GS instead of AS : 
1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
2) grant = larger in scope than AS (not only authorization), as it at least includes idclaims + other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick

As for "Client", if most people think it is problematic, it seems a good reason to change if we find a better alternative. 
Quoting Dick again: "The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context." and later "I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC."

So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis). 

Cheers
Fabien




On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
I would be against using "grant" as both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant" is in the verb: "granted").

Using it as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The Grant Server issues a grant to the Grant Client representing access that has been granted"

Whether the access takes place via a token being returned and used at a resource server, or "claims" that are directly returned from the "Grant Server" I think should be largely irrelevant when it comes to the naming of the roles.

In almost all use cases that I have seen the "Grant Server" is making a policy based decision "to grant" access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
 - identity attributes for the end user
 - verify an identity attribute (e.g. that user is over 18)
 - all users photos at resource server X
 - a single photo with id 12345 at resource server Y
 - resource of type X at any resource server that trusts the Grant Server
 - call a payment API with specific properties (e.g. amount < 5)
 - call a file storage API
 - call a "contract signing" API with specific properties (e.g. contract hash of xxx,)
 
While "client" is problematic, it does now have wide spread usage, so perhaps we are stuck with it. 
However I agree with Justin and think "Grant Client" makes things more confusing.

What is wrong with keeping "Client" and "Authorization Server"? 

Dave




Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.




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



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


--------------A150B5871AB9E21F606EA9D7-- From nobody Fri Aug 14 09:13:39 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 AB93E3A0D94 for ; Fri, 14 Aug 2020 09:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 (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 Bi3vr6cMG5j0 for ; Fri, 14 Aug 2020 09:13:35 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 65E113A0D91 for ; Fri, 14 Aug 2020 09:13:34 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id g8so7913873wmk.3 for ; Fri, 14 Aug 2020 09:13:34 -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=87Ij3Tq3qF038tFLP1tHUgrW0lHCKiInMjd7mncdV4A=; b=VU8wJ6+lr2fqQdqNKhC8+yA/q7kXf80/SRUrKVpvqGewqnY806KcKDVJ1CrFrbUbeU +3GjUFGrWeo//Oy70LYufGd1UHXLz45K1Uv1XjR6oXsgn75goRKqLrVjcBs+zCJxciel zQLPiatNpXou4UMWFzZ5bf23+MKDnfqqFE+6E= 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=87Ij3Tq3qF038tFLP1tHUgrW0lHCKiInMjd7mncdV4A=; b=X7BDumsBnvy1QRSKkKcGoyceYe7bv4ZqJT36PtpSZPh8OBUS7u1SMKmqNjVgqMA+o4 eosjCfojSqE7bUDKE4SlEm0CSjhqD7ZvYg2mUMI3GWvhzdKLmPOC/b/WWH8LW8PtmL2l TLmHTzi4yKqjXqaEAHWlfozJPa2YuNCI0BVUsmv2DJWKJQQ0t9LOfhye0B+tZFwLXCJ/ +R7o2q6hQPIMGg7DehRu1xYLGrIAN8xA2d8tzeMVwqcTKi3i/HFDfi3r3+fjYuWXdCLj AzVttk+eoQQTPon3t+skJBvxj9sZDyJhsv05K+DknHT2+ILXT6WPOJjzkNpcgQTse5N5 xj8g== X-Gm-Message-State: AOAM5304GIwwrkEVsiwCNMNC2xXwQeRXVwQrwbW2ugiIekHwGZiPGGB6 yjD0ckZQXYfJCNh2xY0YwhIdLfzVrO6XbNFwG+Hv+g== X-Google-Smtp-Source: ABdhPJwyhRdE4Ud+Q1EMStwiGDenVExULgyGR+lWmKx8AOyH87AsqEZlzwQVKwYsVNJImCCeXt1GLeQGX9HOHI9UWQk= X-Received: by 2002:a1c:b145:: with SMTP id a66mr3332786wmf.133.1597421612383; Fri, 14 Aug 2020 09:13:32 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> In-Reply-To: <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> From: Francis Pouatcha Date: Fri, 14 Aug 2020 12:13:21 -0400 Message-ID: To: Denis Cc: Dick Hardt , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c35df705acd8b3a8" Archived-At: Subject: Re: [GNAP] User consent 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: Fri, 14 Aug 2020 16:13:38 -0000 --000000000000c35df705acd8b3a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Small digest of the consent discussion into the suggested abstract flow. Please do not nail on the words used (just working assumptions). - GS is used to refer to the token manager (what Justin calls Delegation Server (DS) - handles the back-channel stuff) - AS is used to refer to the authorization server (what Justin calls Interaction Server (IS) - handles the front-channel stuff) - (End User), (Client) are sample entities materializing the corresponding roles (in oAuth2 for example) Added Separation between GS and AS (resp. DS and IS sse above) - 3a: GS forwards request for the RC consent to an AS, that knows how to interact with the RC - 3b: AS returns RC consent to GS. This separation might help draw a line between token management and user authorization. This is essential for forward thinking into the world of Fido, SSI, DID. Display front channel and back channel (At the Abstraction Level-0 -GNAP, this shall not matter.) Steps (1, 4, 7) are good candidates for a front channel, as we are interacting with a potential (End User). Steps (2, 3, 5 , 6) are good candidates for back channel. Steps (3a, 3b) are candidates for both, as AS might be running on a user device. Here is the new diagram. +-----------+ +--------------+ +----+ +----+ +----+ +---------------------+ | Requestor | | Orchestrator | | | | | | | | Resource Controller | | | | | | RS | | GS | | AS | | | |(End User) | | (Client) | | | | | | | | (End User) | +-----------+ +--------------+ +----+ +----+ +----+ +---------------------+ |(1) ServiceRequest | | | | | |---------------------->| | | | | | |(2) ServiceIntent:AuthZChallenge | | |<---------->| | | | | | | | | | | |(3) AuthZRequest(AuthZChallenge) | | |------------------->| | | | | | |(3a)ConsentRequest(AuthZChallenge) | | | |------->| | | | | | |(4) ConsentRequest:Consent | | | | |<-------------->| | | | |(3b)UserConsent | | | | |<-------| | | |(5) GrantAccess(AuthZ). | | | |<-------------------| | | | | | | | | | |(6) ServiceRequest(AuthZ):ServiceResponse. | | |<---------->| | | | |(7) ServiceResponse | | | | | |<----------------------| | | | | + + + + + + Best regards. /Francis On Fri, Aug 14, 2020 at 6:14 AM Denis wrote: > This is a new thread built from "Revisiting the photo sharing example (a > driving use case for the creation of OAuth)" > > Hi Dick, > > I don't see how we can technically standardize a user experience, and it > is not clear why a standard would be needed for interoperability. > > I already wrote a proposal and made it available to the mailing list. > > An access will be granted by a RS based on an mathematical expression > which is formed using some combination of AND and OR conditions. > > Examples of combinations: > > *condition 1* AND > *condition 2 condition 1* OR *condition 2* > (*condition 1* AND *condition 2)* OR > *condition 3 (condition 1* OR *condition 2)* AND *condition 3* > > The following notation is being used for the *conditions*: > > *condition x* =3D { AS identifier + set of attributes types } > > Each RS internally constructs an *authorization table* with the following > content: > > 1=C2=B0 For the "authentication" operation: either FIDO U2F or a mathema= tical > expression using conditions; > > 2=C2=B0 For any other operation: a mathematical expression using conditi= ons. > > Given the operation selected by the client, the RS returns the appropriat= e > mathematical expression and only the associated conditions > used in that mathematical expression. The User may then decide whether > they are appropriate to him or not. > > In many jurisdictions there are regulations regarding what information > needs to be conveyed to a user, and potentially a consent requirement, > for example a site explaining its use of cookies -- but I don't see how > IETF would play a role in that. > > On a related note, the browsers attempted to standardize the username / > password prompt, and that has been rejected by pretty much every site. > The only site I've visited in the last decade that has used the browsers' > built in username / password prompt was the W3C site -- and it was a > frustrating > experience since there was no button for account recovery -- it would jus= t > keep popping up. > > What I am proposing is unrelated to the two above cases you mention. > > Denis > > > > =E1=90=A7 > > On Thu, Aug 13, 2020 at 10:29 AM Denis wrote: > >> Dick, >> >> I think Tom's objection, and I agree with it, is that humans don't >> interact in bits and bytes. >> >> I think it is useful to separate human interactions with software from >> software interactions with software. >> The latter we can standardize, the former we can call out as part of the >> overall process, but it is not something >> that is testable or required for interop, so I would argue human to >> software interactions are NOT part of the protocol. >> >> I disagree. A set of a choices should be presented by the RS to the >> Client in a standardized way. The choices made by the user >> should be locally recorded by the Client, hence the RS does not need to >> be informed of these choices. The RS will only know >> the end result of these choices when/if it gets back one or more access >> tokens. >> >> Human to software interactions should be part of the protocol. >> >> RS to Client: a set of choices >> >> Client to RS: Done (choices have been done by the user). >> >> Denis >> >> >> >> =E1=90=A7 >> >> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: >> >>> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure wher= e the objection >>> you=E2=80=99re raising comes from. >>> >>> Also, whatever roles we define here, whether software or human-ware, >>> they need to be related to the protocol. >>> >>> =E2=80=94 Justin >>> >>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>> wrote: >>> >>> I strong object to the objectification of human users. It is way past >>> time that the IETF becaume user oriented instead of web service oriente= d. >>> users are human in my language. >>> Peace ..tom >>> >>> >>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >>> >>>> If defined as the party operating the client software, then the user i= s >>>> a role. I believe this is more accurate and inclusive than the definit= ion >>>> you have proposed with the user as an entity. >>>> >>>> - Justin >>>> ________________________________________ >>>> From: Dick Hardt [dick.hardt@gmail.com] >>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>> To: Francis Pouatcha >>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>>> driving use case for the creation of OAuth) >>>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the protocol in how I am defining >>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>> >>>> I also think that (2) could be an extension to GNAP, rather than part >>>> of the core protocol. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>> > wrote: >>>> In this context, I suggest we pick some words to work with, and sharpe= n >>>> them as we move on, discover and map new use cases to the protocol. >>>> >>>> In this diagram from the original thread ( >>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOG= Nw/), >>>> I replaced the words: >>>> >>>> +-----------+ +--------------+ +----+ +----+ >>>> +---------------------+ >>>> | Requestor | | Orchestrator | | | | GS | | Resource >>>> Controller | >>>> | was | | was | | RS | | or | | was >>>> | >>>> | User | | Client | | | | AS | | Resource >>>> Owner | >>>> +-----------+ +--------------+ +----+ +----+ >>>> +---------------------+ >>>> |(1) ServiceRequest | | | | >>>> |---------------------->| | | | >>>> | |(2) ServiceIntent:AuthZChallenge | >>>> | |<---------->| | | >>>> | | | | | >>>> | |(3) AuthZRequest(AuthZChallenge) | >>>> | |------------------->| | >>>> | | | |(4) ConsentRequest:Gra= nt >>>> | | | |<-------------->| >>>> | |(5) GrantAccess(AuthZ) | >>>> | |<-------------------| | >>>> | | | | | >>>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>>> | |<---------->| | | >>>> |(7) ServiceResponse | | | | >>>> |<----------------------| | | | >>>> + + + + + >>>> >>>> The purpose of the GNAP protocol is to help negotiate access to a >>>> protected resource. It starts with a requestor delegating activity to = an >>>> orchestrator. These are all roles, no entities. Let focus on mapping t= he >>>> use cases to the protocol roles and interactions so wwe can discover w= hat >>>> is missing. >>>> >>>> It seems cumbersome to use it in discussions as it is impossible to >>>> give the word "Client" a clear definition. >>>> >>>> We can mention in the final document, that the "Orchestrator" (or >>>> whatever word we finally use) plays the same role as the "Client" in o= Auth2. >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>> dick.hardt@gmail.com>> wrote: >>>> I agree with Justin. Redefining well used terms will lead to >>>> significant confusion. If we have a different role than what we have h= ad in >>>> the past, then that role should have a name not being used already in = OAuth >>>> or OIDC. >>>> >>>> Given what we have learned, and my own experience explaining what a >>>> Client is, and is not, improving the definition for Client could prove >>>> useful. I am not suggesting the term be redefined, but clarified. >>>> >>>> For example, clarifying that a Client is a role an entity plays in the >>>> protocol, and that the same entity may play other roles at other times= , or >>>> some other language to help differentiate between "role" and "entity". >>>> >>>> /Dick >>>> [ >>>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20= %3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90= =A7 >>>> >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>> jricher@mit.edu>> wrote: >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bet= ter fit, but I=E2=80=99m >>>> not really in favor of taking an existing term and applying a complete= ly >>>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>>> and come up with a new, more specific and accurate term for the role t= han >>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely dif= ferent. We did this >>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserve= r=E2=80=9D on its own but instead >>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>> >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is >>>> ignore the fact that GNAP is going to be coming up in a world that is >>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t ha= ve a blank >>>> slate to work with, but neither are we bound to use the same terms and >>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>> wparad@rhosys.ch>> wrote: >>>> >>>> I think that is fundamentally part of the question: >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion >>>> >>>> If we say that this document assumes OAuth2.0 terminology, then we >>>> should not change the meanings of any definition. If we are saying thi= s >>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the= best >>>> word for the job and ignore conflicting meanings from OAuth 2.0. I hav= e a >>>> lot of first hand experience of industries "ruining words", and attemp= ting >>>> to side-step the problem rather than redefining the word just confuses >>>> everyone as everyone forgets the original meaning as new documents com= e >>>> out, but the confusion with the use of a non-obvious word continues. >>>> >>>> Food for thought. >>>> - Warren >>>> >>>> [ >>>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZ= OsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hj= uIm9GCeBRRzrSc8kWcUSNtuA >>>> ] >>>> >>>> Warren Parad >>>> Founder, CTO >>>> >>>> Secure your user data and complete your authorization architecture. >>>> Implement Authress. >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>> kaduk@mit.edu>> wrote: >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a response similar to the >>>> one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in us= e here. >>>> What >>>> > > you describe as RS2, which might in fact be an RS unto itself, is = a >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client= of RS1/. What you >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world= , but it is not at >>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>> > > entities below, but it makes it difficult to hold a discussion if = we >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can >>>> define >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>> definitions, >>>> > > but we=E2=80=99ve got a chance to be more precise with how we defi= ne things. >>>> > >>>> > In the ISO context, each document must define its own terminology. T= he >>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>> section >>>> > but does not prevent it either. The vocabulary is limited and as lon= g >>>> as >>>> > we clearly define what our terms are meaning, we can re-use a term >>>> already >>>> > used in another RFC. This is also the ISO approach. >>>> >>>> Just because we can do something does not necessarily mean that it is = a >>>> good idea to do so. We are clear that we are producing a protocol tha= t >>>> is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted >>>> Dick to >>>> use the term "GS" in XAuth, picking a name that was not already used i= n >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> 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/ >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000c35df705acd8b3a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small digest of the consent discussion into the suggested = abstract flow. Please do not nail on the words used (just working assumptio= ns).
- GS is used to refer to the token manager (what Justin calls Dele= gation Server (DS) - handles the back-channel stuff)
- AS is used= to refer=C2=A0to the authorization server=C2=A0(what Justin calls Interact= ion Server (IS) - handles the front-channel stuff)
- (End User), (Clie= nt) are sample entities materializing the corresponding roles (in oAuth2 fo= r example)

Added Separation between GS and AS (resp. DS = and IS sse above)
- 3a: GS forwards request for the RC consent to= an AS, that knows how to interact with the RC
- 3b: AS returns R= C consent to GS.
This separation might help draw a line between t= oken management and user authorization. This is essential for forward think= ing into the world of Fido, SSI, DID.

Display fron= t channel and back channel (At the Abstraction Level-0 -GNAP, this shall no= t matter.)
Steps (1, 4, 7) are good candidates for a front channe= l, as we are interacting with a potential (End User).
Steps (2, 3= , 5 , 6) are good candidates for back channel.
Steps (3a, 3b) are= candidates for both, as AS might be running on a user device.
Here is the new diagram.

+-----------+ =C2=A0 =C2= =A0 =C2=A0+--------------+ =C2=A0+----+ =C2=A0+----+=C2=A0=C2=A0=C2=A0+----= +=C2=A0=C2=A0+---------------------+
| Requestor | =C2=A0 =C2=A0 =C2=A0| Orchestrator | =C2=A0| =C2=A0 =C2= =A0| =C2=A0|=C2=A0 =C2=A0 |=C2=A0=C2=A0=C2=A0|=C2=A0 =C2=A0 |=C2=A0=C2=A0| = Resource Controller |
|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0| RS | =C2=A0| GS |=C2=A0=C2=A0=C2=A0| = 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|
|(End User)= | =C2=A0 =C2=A0 =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 =C2=A0 (End User)=C2=A0 =C2=A0 =C2=A0|
+-----------+ =C2=A0 =C2=A0 =C2=A0+--------------+ =C2= =A0+----+ =C2=A0+----+=C2=A0=C2=A0=C2=A0+----+=C2=A0=C2=A0+----------------= -----+
=C2=A0 |(1) ServiceRequest= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |---------------------->| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0|=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<---------->| =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =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) AuthZRequest(AuthZChallenge)=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |--------------= ----->|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|(3a)ConsentRequest(AuthZChallenge)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =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) ConsentRequest:Consent<= 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 =C2=A0 =C2=A0 =C2=A0= |(3b)UserConsent=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=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) GrantAccess(AuthZ).=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(6) ServiceRequest= (AuthZ):ServiceResponse.=C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<---------->= |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceRespo= nse =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2= =A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 +

Bes= t regards.
/Francis


On Fri, Aug 14, 202= 0 at 6:14 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
This is a new thread built from "R= evisiting the photo sharing example (a driving use case for the creation of OAuth)"

Hi Dick,

=20
I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted b= y a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

Examples of combinations:

condition 1 AND condition= 2
condition 1 OR condition 2
(condition 1 AND condition 2= ) OR condition 3
(condition 1 OR condition 2) AND <= /span>condition 3=

The following notation is being used for the conditions:

condition x =3D { AS identifier + set of attributes types }

Each RS internally constructs an authorization table with the following content:

1=C2=B0=C2=A0 For th= e "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

2=C2=B0=C2=A0 For an= y other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

=C2=A0In many jurisdictions there are regulations regarding wh= at information needs to be conveyed to a user, and potentially a consent requirement,
for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that.=C2=A0

On a related note, the browsers=C2=A0attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis



3D""==E1=90=A7

On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
Dick,

I think Tom's objection, and I agree wit= h it, is that humans don't interact in bits and bytes.=C2= =A0

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.=C2=A0 A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



3D""=E1=90=A7

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It=E2=80=99s a role fulfilled by a person, so I=E2= =80=99m not sure where the objection you=E2=80=99re raising comes f= rom.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

=C2=A0=E2=80=94 Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_Kimj= OBJqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orc= hestrator |=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | GS |=C2=A0 | R= esource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |= =C2=A0 =C2=A0 Resource Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2= =A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2= =A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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)= ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|<= ;-------------->|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clea= r definition.

We can mention in the final document, that the "Orchestrator&q= uot; (or whatever word we finally use) plays the same role as the "Client= " in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role&q= uot; and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBn= bWFpbC5jb20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d5= 0e00dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I=E2=80=99m in favor of coming up with = a new term that=E2=80=99s a better fit, but I= =E2=80=99m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come= up with a new, more specific and accurate term for the role than to define =E2=80=9Ccl= ient=E2=80=9D as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cc= onsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2= =80=9D and =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do i= s ignore the fact that GNAP is going to be coming up in a world that is already permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have = a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIr= SqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45= YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p&g= t;.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still= a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in O= Auth parlance because it is /a client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80= =9D has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t= just re-use existing terms with new definitions,
> > but we=E2=80=99ve got a chanc= e to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, p= icking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth


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


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


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


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--000000000000c35df705acd8b3a8-- From nobody Fri Aug 14 09:33:44 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 F1C653A0E41 for ; Fri, 14 Aug 2020 09:33:41 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 frII72wqWP14 for ; Fri, 14 Aug 2020 09:33:40 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 69FB23A0D96 for ; Fri, 14 Aug 2020 09:33:26 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id h4so11361086ioe.5 for ; Fri, 14 Aug 2020 09:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=b6YN4s8/rkzPWN8jqSMbleH2gW6Y0DedWCDR1LuMAi8=; b=a6TpjUZ19UXB1JuR2YiVq5JbdGWdKDaRPJAf+L7M//6+0eMAxlzFKEOdjCzNabcaMr 0VC189E16MEUhf6a19V8EMEqbX8Qv3sbehK26+9nKFqfZIXrVNmszgMzhGqNtho6BR33 pHhiDW5K/4+ncxL8dhkwL/YrjaHfwy7h5Fb/d8pFdrvV9CPD/YX5YoQbCpZmNaT0bdvX JI0Y8I8/p30BnxSWd4QYbETI/PhScnPvt6mMwAykiJItw7r0XK7THfmggEeHU3vBFf+3 396OWaN6NwJGCgpm1VikIpQiigfApUt8cMAn643McI6dadxQh1ehbF4MyyciqicAQa9c huGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b6YN4s8/rkzPWN8jqSMbleH2gW6Y0DedWCDR1LuMAi8=; b=mioilfqJzqaK0fvENFkxF3rCDLXzrS8WYuY93hCVCjXig1lZAX2+IJjZfYF7Jn+9yx VIOOJbqkkGt4F2rdwd0tbJQQPQw6k9HIlf/E1e9L+9OHTAzlT74ByzXAw2qEdicP7N8D a3Qz7rrOggSxpEpgiZNf823vyr4M2KhuXah+fhS9WBnjzFXQlD8Ka5CYfYd7wa85SqiS aEKeucub1EI+yvkRRNtcoELmfFuNbwObPCuvffrt2QRuWBRizHmiZYfE6mwzbT2/OoZU S5gVWWNsKIIxjV+4D8D5GxHXLSako2g7XOU41d7j0IjxgSkb6/hi7nKQdEOeXSeJZQuI kShQ== X-Gm-Message-State: AOAM532t1TOBz1WD5EtjJMEz9mURKEhAPoO8MmnSskp8WUJSuJ62hW0c 7kopdCcwMfKc1Tiar3HJ2kbD01MI0PsVArOE8XAcSdnOBJaXhg== X-Google-Smtp-Source: ABdhPJwmsBUOSojfUtKOYDchQl9IN8zvrsF9w3HHGi9PPpYXyhTpbGhxP7ybKmzfmIqO7C91YuVrYpwx17/jH+MdWr8= X-Received: by 2002:a05:6638:d46:: with SMTP id d6mr3388471jak.124.1597422805446; Fri, 14 Aug 2020 09:33:25 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Fri, 14 Aug 2020 18:33:13 +0200 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000dff37705acd8fa55" Archived-At: Subject: [GNAP] Implementation of RS hiding 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: Fri, 14 Aug 2020 16:33:42 -0000 --000000000000dff37705acd8fa55 Content-Type: text/plain; charset="UTF-8" Hello, Following discussions we had on the mailing list, here's a mvp which includes RS hiding. https://github.com/acertio/mvp_gnap_privacy => it works fine. In the same release we also improved the IS flow (including Justin's feedback), and started to implement a more realistic use case. The documentation has been updated accordingly. Fabien --000000000000dff37705acd8fa55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

Following discussions we h= ad on the mailing list, here's a mvp which includes RS hiding.=C2=A0

=3D> i= t works fine.

In the same release we also improved= the IS flow (including Justin's feedback),=C2=A0and started to impleme= nt a more realistic=C2=A0use case.=C2=A0
The documentation has be= en updated accordingly.=C2=A0

Fabien
--000000000000dff37705acd8fa55-- From nobody Fri Aug 14 09:39:22 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 1E4113A0E4F for ; Fri, 14 Aug 2020 09:39:20 -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=unavailable 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 t29Oe1nhQzCQ for ; Fri, 14 Aug 2020 09:39:15 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 18AF53A0E3F for ; Fri, 14 Aug 2020 09:39:15 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id t7so8061091otp.0 for ; Fri, 14 Aug 2020 09:39:15 -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=36mRrNSPnnXhNwmxeQxPA/s923RzireFi8FYpgp5RsI=; b=JsdQ3H0aXmPTdzdtxCtA1dpVnZ3y8Lct/1VmOsiPRY+vhCxgnIKu5ZTBBeZ5Klm4Qf qDsk+oT5vS4rOuUbaCzQR0pwvXXX0kEkn6LrDVWXg9TRSX+BCJKjvcl6HCe2x93H6d9v qd6pgsAZvpIhdqFUnuguC4kOxvMcCU4Jfqxj+gyha35X9A4FUaJ9IdCRobXcg+On3vwB l0vOgZHlT1MnRwYwczPdhvNlvYOpy1OA3WlwCCkF0L64dchFD1Wec0lHetjQZgSZpdb2 OG31WOc/wb/TuPhWDW6NxMLBiAtbo4Jz32lFA5/2SJ6hdiemz/12XOdr04JRP9rNhOUF VRow== 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=36mRrNSPnnXhNwmxeQxPA/s923RzireFi8FYpgp5RsI=; b=a24xwK0jMfzMCXl8LM7AnhnMrv7pIq7tqw32F3lryk3/mjv30IBU2ln6pOhUwacQ38 4W4szh3KpTT1B3xvfKJw5I3dveyJqw2kyKoEpoIibFqS+zuPyeGmMzcka+vNKIJM+NlN 5CjiNGkUrKSIAXZvOCV2xlVrDu3Zzsc4wKW57sJQsB3qWmjsZI5VLML6Qfbe5FK2nkkf iWFIrY6yCSXlm9bEGdcP47CDmliy4pqus0PgD7s/OyB2dK+Ka1BSdzNzI3/my+n7euPd mjDQsqIi/JPEUY0pF6NxT/21wUU0DUxaiYitZT9OKjpkfjlQYu1JJu6smJguVbkvlXFc n3Yg== X-Gm-Message-State: AOAM530hzX5sJMhsvW9wlD2l7NSlQeN7T4ahCEcmzxVXhC631yymkL7X Iu72dOnbrdyJ8NoepMfRJdGH4AyTDTgi5WZLE6A= X-Google-Smtp-Source: ABdhPJzWtPTzqZ9kkri+ejP33opmSMCgjku0xKEnIVuXSWyyjN8uNAWwalNz8fN0EJBgWf+Mt51PjbCONzREOBGaraA= X-Received: by 2002:a9d:84c:: with SMTP id 70mr2425019oty.358.1597423154144; Fri, 14 Aug 2020 09:39:14 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> In-Reply-To: From: Tom Jones Date: Fri, 14 Aug 2020 09:39:02 -0700 Message-ID: To: Francis Pouatcha Cc: Denis , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000a8abe105acd90f6f" Archived-At: Subject: Re: [GNAP] User consent 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: Fri, 14 Aug 2020 16:39:20 -0000 --000000000000a8abe105acd90f6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here are some proposals that are working their way through other channels. 1. on consent grant.: https://wiki.idesg.org/wiki/index.php/Consent_Grant 2 on delegations: https://wiki.idesg.org/wiki/index.php/Delegation Comments are welcomed. Peace ..tom On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha wrote: > Small digest of the consent discussion into the suggested abstract flow. > Please do not nail on the words used (just working assumptions). > - GS is used to refer to the token manager (what Justin calls Delegation > Server (DS) - handles the back-channel stuff) > - AS is used to refer to the authorization server (what Justin calls > Interaction Server (IS) - handles the front-channel stuff) > - (End User), (Client) are sample entities materializing the correspondin= g > roles (in oAuth2 for example) > > Added Separation between GS and AS (resp. DS and IS sse above) > - 3a: GS forwards request for the RC consent to an AS, that knows how to > interact with the RC > - 3b: AS returns RC consent to GS. > This separation might help draw a line between token management and user > authorization. This is essential for forward thinking into the world of > Fido, SSI, DID. > > Display front channel and back channel (At the Abstraction Level-0 -GNAP, > this shall not matter.) > Steps (1, 4, 7) are good candidates for a front channel, as we are > interacting with a potential (End User). > Steps (2, 3, 5 , 6) are good candidates for back channel. > Steps (3a, 3b) are candidates for both, as AS might be running on a user > device. > > Here is the new diagram. > > +-----------+ +--------------+ +----+ > +----+ +----+ +---------------------+ > | Requestor | | Orchestrator | | | | | | | | Resource > Controller | > | | | | | RS | | GS | | AS | | > | > |(End User) | | (Client) | | | | | | | | (End > User) | > +-----------+ +--------------+ +----+ > +----+ +----+ +---------------------+ > |(1) ServiceRequest | | | | = | > |---------------------->| | | | = | > | |(2) ServiceIntent:AuthZChallenge = | > | |<---------->| | | = | > | | | | | = | > | |(3) AuthZRequest(AuthZChallenge) = | > | |------------------->| | = | > | | | > |(3a)ConsentRequest(AuthZChallenge) > | | | |------->| = | > | | | | |(4) > ConsentRequest:Consent > | | | | |<-------------->= | > | | | |(3b)UserConsent = | > | | | |<-------| = | > | |(5) GrantAccess(AuthZ). | = | > | |<-------------------| | = | > | | | | | = | > | |(6) ServiceRequest(AuthZ):ServiceResponse. = | > | |<---------->| | | = | > |(7) ServiceResponse | | | | = | > |<----------------------| | | | = | > + + + + + = + > > Best regards. > /Francis > > > On Fri, Aug 14, 2020 at 6:14 AM Denis wrote: > >> This is a new thread built from "Revisiting the photo sharing example (a >> driving use case for the creation of OAuth)" >> >> Hi Dick, >> >> I don't see how we can technically standardize a user experience, and it >> is not clear why a standard would be needed for interoperability. >> >> I already wrote a proposal and made it available to the mailing list. >> >> An access will be granted by a RS based on an mathematical expression >> which is formed using some combination of AND and OR conditions. >> >> Examples of combinations: >> >> *condition 1* AND >> *condition 2 condition 1* OR *condition 2* >> (*condition 1* AND *condition 2)* OR >> *condition 3 (condition 1* OR *condition 2)* AND *condition 3* >> >> The following notation is being used for the *conditions*: >> >> *condition x* =3D { AS identifier + set of attributes types } >> >> Each RS internally constructs an *authorization table* with the >> following content: >> >> 1=C2=B0 For the "authentication" operation: either FIDO U2F or a >> mathematical expression using conditions; >> >> 2=C2=B0 For any other operation: a mathematical expression using condit= ions. >> >> Given the operation selected by the client, the RS returns the >> appropriate mathematical expression and only the associated conditions >> used in that mathematical expression. The User may then decide whether >> they are appropriate to him or not. >> >> In many jurisdictions there are regulations regarding what information >> needs to be conveyed to a user, and potentially a consent requirement, >> for example a site explaining its use of cookies -- but I don't see how >> IETF would play a role in that. >> >> On a related note, the browsers attempted to standardize the username / >> password prompt, and that has been rejected by pretty much every site. >> The only site I've visited in the last decade that has used the browsers= ' >> built in username / password prompt was the W3C site -- and it was a >> frustrating >> experience since there was no button for account recovery -- it would >> just keep popping up. >> >> What I am proposing is unrelated to the two above cases you mention. >> >> Denis >> >> >> >> =E1=90=A7 >> >> On Thu, Aug 13, 2020 at 10:29 AM Denis wrote: >> >>> Dick, >>> >>> I think Tom's objection, and I agree with it, is that humans don't >>> interact in bits and bytes. >>> >>> I think it is useful to separate human interactions with software from >>> software interactions with software. >>> The latter we can standardize, the former we can call out as part of th= e >>> overall process, but it is not something >>> that is testable or required for interop, so I would argue human to >>> software interactions are NOT part of the protocol. >>> >>> I disagree. A set of a choices should be presented by the RS to the >>> Client in a standardized way. The choices made by the user >>> should be locally recorded by the Client, hence the RS does not need to >>> be informed of these choices. The RS will only know >>> the end result of these choices when/if it gets back one or more access >>> tokens. >>> >>> Human to software interactions should be part of the protocol. >>> >>> RS to Client: a set of choices >>> >>> Client to RS: Done (choices have been done by the user). >>> >>> Denis >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: >>> >>>> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure whe= re the objection >>>> you=E2=80=99re raising comes from. >>>> >>>> Also, whatever roles we define here, whether software or human-ware, >>>> they need to be related to the protocol. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>>> wrote: >>>> >>>> I strong object to the objectification of human users. It is way past >>>> time that the IETF becaume user oriented instead of web service orient= ed. >>>> users are human in my language. >>>> Peace ..tom >>>> >>>> >>>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >>>> >>>>> If defined as the party operating the client software, then the user >>>>> is a role. I believe this is more accurate and inclusive than the >>>>> definition you have proposed with the user as an entity. >>>>> >>>>> - Justin >>>>> ________________________________________ >>>>> From: Dick Hardt [dick.hardt@gmail.com] >>>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>>> To: Francis Pouatcha >>>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>>>> driving use case for the creation of OAuth) >>>>> >>>>> Hi Francis >>>>> >>>>> The user is an entity, not a role in the protocol in how I am definin= g >>>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>>> >>>>> I also think that (2) could be an extension to GNAP, rather than part >>>>> of the core protocol. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>>> > wrote: >>>>> In this context, I suggest we pick some words to work with, and >>>>> sharpen them as we move on, discover and map new use cases to the pro= tocol. >>>>> >>>>> In this diagram from the original thread ( >>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JO= GNw/), >>>>> I replaced the words: >>>>> >>>>> +-----------+ +--------------+ +----+ +----+ >>>>> +---------------------+ >>>>> | Requestor | | Orchestrator | | | | GS | | Resource >>>>> Controller | >>>>> | was | | was | | RS | | or | | was >>>>> | >>>>> | User | | Client | | | | AS | | Resource >>>>> Owner | >>>>> +-----------+ +--------------+ +----+ +----+ >>>>> +---------------------+ >>>>> |(1) ServiceRequest | | | | >>>>> |---------------------->| | | | >>>>> | |(2) ServiceIntent:AuthZChallenge | >>>>> | |<---------->| | | >>>>> | | | | | >>>>> | |(3) AuthZRequest(AuthZChallenge) | >>>>> | |------------------->| | >>>>> | | | |(4) >>>>> ConsentRequest:Grant >>>>> | | | |<-------------->| >>>>> | |(5) GrantAccess(AuthZ) | >>>>> | |<-------------------| | >>>>> | | | | | >>>>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>>>> | |<---------->| | | >>>>> |(7) ServiceResponse | | | | >>>>> |<----------------------| | | | >>>>> + + + + + >>>>> >>>>> The purpose of the GNAP protocol is to help negotiate access to a >>>>> protected resource. It starts with a requestor delegating activity to= an >>>>> orchestrator. These are all roles, no entities. Let focus on mapping = the >>>>> use cases to the protocol roles and interactions so wwe can discover = what >>>>> is missing. >>>>> >>>>> It seems cumbersome to use it in discussions as it is impossible to >>>>> give the word "Client" a clear definition. >>>>> >>>>> We can mention in the final document, that the "Orchestrator" (or >>>>> whatever word we finally use) plays the same role as the "Client" in = oAuth2. >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>>> > wrote: >>>>> I agree with Justin. Redefining well used terms will lead to >>>>> significant confusion. If we have a different role than what we have = had in >>>>> the past, then that role should have a name not being used already in= OAuth >>>>> or OIDC. >>>>> >>>>> Given what we have learned, and my own experience explaining what a >>>>> Client is, and is not, improving the definition for Client could prov= e >>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>> >>>>> For example, clarifying that a Client is a role an entity plays in th= e >>>>> protocol, and that the same entity may play other roles at other time= s, or >>>>> some other language to help differentiate between "role" and "entity"= . >>>>> >>>>> /Dick >>>>> [ >>>>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb2= 0%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90= =A7 >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>> jricher@mit.edu>> wrote: >>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a be= tter fit, but I=E2=80=99m >>>>> not really in favor of taking an existing term and applying a complet= ely >>>>> new definition to it. In other words, I would sooner stop using =E2= =80=9Cclient=E2=80=9D >>>>> and come up with a new, more specific and accurate term for the role = than >>>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely di= fferent. We did this >>>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserv= er=E2=80=9D on its own but instead >>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>> >>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>> ignore the fact that GNAP is going to be coming up in a world that is >>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t h= ave a blank >>>>> slate to work with, but neither are we bound to use the same terms an= d >>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>>> wparad@rhosys.ch>> wrote: >>>>> >>>>> I think that is fundamentally part of the question: >>>>> We are clear that we are producing a protocol that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion >>>>> >>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>> should not change the meanings of any definition. If we are saying th= is >>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick th= e best >>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I ha= ve a >>>>> lot of first hand experience of industries "ruining words", and attem= pting >>>>> to side-step the problem rather than redefining the word just confuse= s >>>>> everyone as everyone forgets the original meaning as new documents co= me >>>>> out, but the confusion with the use of a non-obvious word continues. >>>>> >>>>> Food for thought. >>>>> - Warren >>>>> >>>>> [ >>>>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdf= ZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6h= juIm9GCeBRRzrSc8kWcUSNtuA >>>>> ] >>>>> >>>>> Warren Parad >>>>> Founder, CTO >>>>> >>>>> Secure your user data and complete your authorization architecture. >>>>> Implement Authress. >>>>> >>>>> >>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>> kaduk@mit.edu>> wrote: >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a response similar to th= e >>>>> one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there=E2=80=99s still a problem with the terminology in u= se here. >>>>> What >>>>> > > you describe as RS2, which might in fact be an RS unto itself, is= a >>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What >>>>> you >>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not >>>>> at >>>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>>> > > entities below, but it makes it difficult to hold a discussion if >>>>> we >>>>> > > aren=E2=80=99t using the same terms. >>>>> > > >>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can >>>>> define >>>>> > > our own terms. The bad news is that this is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>>> definitions, >>>>> > > but we=E2=80=99ve got a chance to be more precise with how we def= ine >>>>> things. >>>>> > >>>>> > In the ISO context, each document must define its own terminology. >>>>> The >>>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>>> section >>>>> > but does not prevent it either. The vocabulary is limited and as >>>>> long as >>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>> already >>>>> > used in another RFC. This is also the ISO approach. >>>>> >>>>> Just because we can do something does not necessarily mean that it is= a >>>>> good idea to do so. We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>> Dick to >>>>> use the term "GS" in XAuth, picking a name that was not already used = in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> 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/ >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- >> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a8abe105acd90f6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are some proposals that are working their way through= other channels.
Comments are welcomed.
Peace ..tom


On Fri, Aug 14, = 2020 at 9:13 AM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
Small digest of = the consent discussion into the suggested abstract flow. Please do not nail= on the words used (just working assumptions).
- GS is used to refer to= the token manager (what Justin calls Delegation Server (DS) - handles the = back-channel stuff)
- AS is used to refer=C2=A0to the authorizati= on server=C2=A0(what Justin calls Interaction Server (IS) - handles the fro= nt-channel stuff)
- (End User), (Client) are sample entities materiali= zing the corresponding roles (in oAuth2 for example)

Add= ed Separation between GS and AS (resp. DS and IS sse above)
- 3a:= GS forwards request for the RC consent to an AS, that knows how to interac= t with the RC
- 3b: AS returns RC consent to GS.
This s= eparation might help draw a line between token management and user authoriz= ation. This is essential for forward thinking into the world of Fido, SSI, = DID.

Display front channel and back channel (At th= e Abstraction Level-0 -GNAP, this shall not matter.)
Steps (1, 4,= 7) are good candidates for a front channel, as we are interacting with a p= otential (End User).
Steps (2, 3, 5 , 6) are good candidates for = back channel.
Steps (3a, 3b) are candidates for both, as AS might= be running on a user device.

Here is the new diag= ram.

+-----------+ =C2=A0 =C2=A0 =C2=A0+--------------+ =C2=A0+= ----+ =C2=A0+----+=C2=A0=C2=A0=C2=A0+----+=C2=A0=C2=A0+--------------------= -+
| Requestor | =C2=A0 =C2=A0 = =C2=A0| Orchestrator | =C2=A0| =C2=A0 =C2=A0| =C2=A0|=C2=A0 =C2=A0 |=C2=A0= =C2=A0=C2=A0|=C2=A0 =C2=A0 |=C2=A0=C2=A0| Resource Controller |
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0| RS | =C2=A0| GS |=C2=A0=C2=A0=C2=A0| 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|
|(End User) | =C2=A0 =C2=A0 =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 =C2=A0 (End User)=C2= =A0 =C2=A0 =C2=A0|
+-----------+ = =C2=A0 =C2=A0 =C2=A0+--------------+ =C2=A0+----+ =C2=A0+----+=C2=A0=C2=A0= =C2=A0+----+=C2=A0=C2=A0+---------------------+
=C2=A0 |(1) ServiceRequest =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 |---------------------->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(2) Servic= eIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |<---------->| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 = =C2=A0 |(3) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |------------------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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|(3a)ConsentRequest(AuthZChallenge)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0|------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =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) ConsentRequest:Consent
=C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |<-------------->|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|(3b)UserConsent=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=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) GrantAccess(AuthZ).= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(6) ServiceRequest(AuthZ):ServiceResponse.= =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<---------->|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 |<----------------------| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 + =C2= =A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +

Best regards.
/F= rancis


On Fri, Aug 14, 2020 at 6:14 AM Denis <= denis.ietf@free.fr<= /a>> wrote:
=20 =20 =20
This is a new thread built from "R= evisiting the photo sharing example (a driving use case for the creation of OAuth)"

Hi Dick,

=20
I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted b= y a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

Examples of combinations:

condition 1 AND condition= 2
condition 1 OR condition 2
(condition 1 AND condition 2= ) OR condition 3
(condition 1 OR condition 2) AND <= /span>condition 3=

The following notation is being used for the conditions:

condition x =3D { AS identifier + set of attributes types }

Each RS internally constructs an authorization table with the following content:

1=C2=B0=C2=A0 For th= e "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

2=C2=B0=C2=A0 For an= y other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

=C2=A0In many jurisdictions there are regulations regarding wh= at information needs to be conveyed to a user, and potentially a consent requirement,
for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that.=C2=A0

On a related note, the browsers=C2=A0attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis



3D""==E1=90=A7

On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
Dick,

I think Tom's objection, and I agree wit= h it, is that humans don't interact in bits and bytes.=C2= =A0

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.=C2=A0 A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



3D""=E1=90=A7

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It=E2=80=99s a role fulfilled by a person, so I=E2= =80=99m not sure where the objection you=E2=80=99re raising comes f= rom.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

=C2=A0=E2=80=94 Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_Kimj= OBJqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2=A0 | Orc= hestrator |=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | GS |=C2=A0 | R= esource Controller |
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |= =C2=A0 =C2=A0 Resource Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2= =A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2= =A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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)= ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|<= ;-------------->|
=C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clea= r definition.

We can mention in the final document, that the "Orchestrator&q= uot; (or whatever word we finally use) plays the same role as the "Client= " in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role&q= uot; and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBn= bWFpbC5jb20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d5= 0e00dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I=E2=80=99m in favor of coming up with = a new term that=E2=80=99s a better fit, but I= =E2=80=99m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come= up with a new, more specific and accurate term for the role than to define =E2=80=9Ccl= ient=E2=80=9D as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cc= onsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2= =80=9D and =E2=80=9CResource Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do i= s ignore the fact that GNAP is going to be coming up in a world that is already permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have = a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIr= SqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45= YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p&g= t;.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80=99s still= a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80=9D in O= Auth parlance because it is /a client of RS1/. What you
> > call a =E2=80=9Cclient=E2=80= =9D has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t= just re-use existing terms with new definitions,
> > but we=E2=80=99ve got a chanc= e to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, p= icking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org= /mailman/listinfo/txauth


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


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


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


--
Francis Pouatcha
Co-Founder and Technical Lead=
adorsys GmbH & Co. KG
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a8abe105acd90f6f-- From nobody Fri Aug 14 09:39:58 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 BAB4F3A0E33 for ; Fri, 14 Aug 2020 09:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j_kd37HZdWnF for ; Fri, 14 Aug 2020 09:39:52 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDF43A0E1E for ; Fri, 14 Aug 2020 09:39:51 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d19 with ME id FUfn230012bcEcA03Ufnmb; Fri, 14 Aug 2020 18:39:50 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 18:39:50 +0200 X-ME-IP: 90.79.51.120 To: Francis Pouatcha Cc: "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> From: Denis Message-ID: Date: Fri, 14 Aug 2020 18:39:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA071D507A1873194207BB77" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] User consent 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: Fri, 14 Aug 2020 16:39:57 -0000 This is a multi-part message in MIME format. --------------EA071D507A1873194207BB77 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Francis, In the proposed flow, between (2) and (3), there should be a flow for the User Consent. That flow is missing. In addition, keep in mind that the Resource Controller (RC) can be an application with no end-user involved. Hence, there is no "consent" from such an application, but only the enforcement of some rules. I do not see the relationship with the topic raised in that thread which is about User Consent based on information provided to the User by the RS. If you want to discuss something else, please open a new thread. Denis > Small digest of the consent discussion into the suggested abstract > flow. Please do not nail on the words used (just working assumptions). > - GS is used to refer to the token manager (what Justin calls > Delegation Server (DS) - handles the back-channel stuff) > - AS is used to refer to the authorization server (what Justin calls > Interaction Server (IS) - handles the front-channel stuff) > - (End User), (Client) are sample entities materializing the > corresponding roles (in oAuth2 for example) > > Added Separation between GS and AS (resp. DS and IS sse above) > - 3a: GS forwards request for the RC consent to an AS, that knows how > to interact with the RC > - 3b: AS returns RC consent to GS. > This separation might help draw a line between token management and > user authorization. This is essential for forward thinking into the > world of Fido, SSI, DID. > > Display front channel and back channel (At the Abstraction Level-0 > -GNAP, this shall not matter.) > Steps (1, 4, 7) are good candidates for a front channel, as we are > interacting with a potential (End User). > Steps (2, 3, 5 , 6) are good candidates for back channel. > Steps (3a, 3b) are candidates for both, as AS might be running on a > user device. > > Here is the new diagram. > > +-----------+  +--------------+  +----+ >  +----+   +----+  +---------------------+ > | Requestor |      | Orchestrator |  |    |  |    |   |    |  | > Resource Controller | > |           |      | |  | RS |  | GS |   | AS |  |                     | > |(End User) |      |   (Client) |  |    |  |    |   |    |  |      > (End User)     | > +-----------+  +--------------+  +----+ >  +----+   +----+  +---------------------+ >   |(1) ServiceRequest     |      |       |        |                | >   |---------------------->|            |       |   |                | >   |                       |(2) ServiceIntent:AuthZChallenge              | >   |                       |<---------->|       |     |                | >   |                       |            |       |        |               | >   |                       |(3) AuthZRequest(AuthZChallenge)              | >   |                       |------------------->|   |                | >   |                       |            | >  |(3a)ConsentRequest(AuthZChallenge) >   |                       |      |       |------->|                | >   |                       |      |       |        |(4) > ConsentRequest:Consent >   |                       |            |       | |<-------------->| >   |                       |            |  |(3b)UserConsent          | >   |                       |            |  |<-------|                | >   |                       |(5) GrantAccess(AuthZ).      |               | >   |                       |<-------------------| |                | >   |                       |            |       |        |               | >   |                       |(6) ServiceRequest(AuthZ):ServiceResponse.    | >   |                       |<---------->|       |     |                | >   |(7) ServiceResponse    |            |       |        |               | >   |<----------------------|            |       |   |                | >   +                       +            +       +        +               + > > Best regards. > /Francis > > > On Fri, Aug 14, 2020 at 6:14 AM Denis > wrote: > > This is a new thread built from "Revisiting the photo sharing > example (a driving use case for the creation of OAuth)" > > Hi Dick, > >> I don't see how we can technically standardize a user experience, >> and it is not clear why a standard would be needed for >> interoperability. > > I already wrote a proposal and made it available to the mailing list. > > An access will be granted by a RS based on an mathematical > expression which is formed using some combination of ANDand OR > conditions. > > Examples of combinations: > > /condition 1/AND/condition 2 > condition 1/OR /condition 2/ > (/condition 1/AND/condition 2)/OR/condition 3 > (condition 1/OR /condition 2)/AND/condition 3/ > > The following notation is being used for the /conditions/: > > /condition x/= { AS identifier + set of attributes types } > > Each RS internally constructs an /authorization table/ with the > following content: > > 1°For the "authentication" operation: either FIDO U2For a > mathematical expression using conditions; > > 2°For any other operation: a mathematical expression using conditions. > > Given the operation selected by the client, the RS returns the > appropriate mathematical expression and only the associated > conditions > used in that mathematical expression. The User may then decide > whether they are appropriate to him or not. > >>  In many jurisdictions there are regulations regarding what >> information needs to be conveyed to a user, and potentially a >> consent requirement, >> for example a site explaining its use of cookies -- but I don't >> see how IETF would play a role in that. >> >> On a related note, the browsers attempted to standardize the >> username / password prompt, and that has been rejected by pretty >> much every site. >> The only site I've visited in the last decade that has used the >> browsers' built in username / password prompt was the W3C site -- >> and it was a frustrating >> experience since there was no button for account recovery -- it >> would just keep popping up. > > What I am proposing is unrelated to the two above cases you mention. > > Denis > >> >> >> ᐧ >> >> On Thu, Aug 13, 2020 at 10:29 AM Denis > > wrote: >> >> Dick, >> >>> I think Tom's objection, and I agree with it, is that humans >>> don't interact in bits and bytes. >>> >>> I think it is useful to separate human interactions with >>> software from software interactions with software. >>> The latter we can standardize, the former we can call out as >>> part of the overall process, but it is not something >>> that is testable or required for interop, so I would argue >>> human to software interactions are NOT part of the protocol. >> >> I disagree.  A set of a choices should be presented by the RS >> to the Client in a standardized way. The choices made by the >> user >> should be locally recorded by the Client, hence the RS does >> not need to be informed of these choices. The RS will only know >> the end result of these choices when/if it gets back one or >> more access tokens. >> >> Human to software interactions should be part of the protocol. >> >> RS to Client: a set of choices >> >> Client to RS: Done (choices have been done by the user). >> >> Denis >> >> >>> >>> ᐧ >>> >>> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer >>> > wrote: >>> >>> It’s a role fulfilled by a person, so I’m not sure where >>> the objection you’re raising comes from. >>> >>> Also, whatever roles we define here, whether software or >>> human-ware, they need to be related to the protocol. >>> >>>  — Justin >>> >>>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>>> >>> > wrote: >>>> >>>> I strong object to the objectification of human users. >>>> It is way past time that the IETF becaume user oriented >>>> instead of web service oriented. >>>> users are human in my language. >>>> Peace ..tom >>>> >>>> >>>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer >>>> > wrote: >>>> >>>> If defined as the party operating the client >>>> software, then the user is a role. I believe this >>>> is more accurate and inclusive than the definition >>>> you have proposed with the user as an entity. >>>> >>>>  - Justin >>>> ________________________________________ >>>> From: Dick Hardt [dick.hardt@gmail.com >>>> ] >>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>> To: Francis Pouatcha >>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; >>>> txauth@ietf.org >>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo >>>> sharing example (a driving use case for the >>>> creation of OAuth) >>>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the protocol >>>> in how I am defining roles, so steps (1) and (7) >>>> are confusing to me on what is happening. >>>> >>>> I also think that (2) could be an extension to >>>> GNAP, rather than part of the core protocol. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>>> >>> >>> >> wrote: >>>> In this context, I suggest we pick some words to >>>> work with, and sharpen them as we move on, discover >>>> and map new use cases to the protocol. >>>> >>>> In this diagram from the original thread >>>> (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), >>>> I replaced the words: >>>> >>>> +-----------+ +--------------+  +----+ +----+ >>>> +---------------------+ >>>> | Requestor |      | Orchestrator |  |    |  | GS >>>> |  | Resource Controller | >>>> |   was     |      |  was      |  | RS |  | or | |  >>>>        was         | >>>> |  User     |      |  Client     |  |    |  | AS |  >>>> |    Resource Owner   | >>>> +-----------+ +--------------+  +----+ +----+ >>>> +---------------------+ >>>>   |(1) ServiceRequest     |           |       |       | >>>> |---------------------->|           |       |       | >>>>   |  |(2) ServiceIntent:AuthZChallenge    | >>>>   |  |<---------->|  |                | >>>>   |                       |           |       |       | >>>>   |  |(3) AuthZRequest(AuthZChallenge)    | >>>>   |  |------------------->|               | >>>>   |                       |           |       |(4) >>>> ConsentRequest:Grant >>>>   |                       |           | >>>>  |<-------------->| >>>>   |  |(5) GrantAccess(AuthZ)            | >>>>   |  |<-------------------|               | >>>>   |                       |           |       |       | >>>>   |  |(6) ServiceRequest(AuthZ):ServiceResponse >>>>   |  |<---------->|  |                | >>>>   |(7) ServiceResponse    |           |       |       | >>>> |<----------------------|           |       |       | >>>>   +                       +           +       +       + >>>> >>>> The purpose of the GNAP protocol is to help >>>> negotiate access to a protected resource. It starts >>>> with a requestor delegating activity to an >>>> orchestrator. These are all roles, no entities. Let >>>> focus on mapping the use cases to the protocol >>>> roles and interactions so wwe can discover what is >>>> missing. >>>> >>>> It seems cumbersome to use it in discussions as it >>>> is impossible to give the word "Client" a clear >>>> definition. >>>> >>>> We can mention in the final document, that the >>>> "Orchestrator" (or whatever word we finally use) >>>> plays the same role as the "Client" in oAuth2. >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>>> >>> >>> >> wrote: >>>> I agree with Justin. Redefining well used terms >>>> will lead to significant confusion. If we have a >>>> different role than what we have had in the past, >>>> then that role should have a name not being used >>>> already in OAuth or OIDC. >>>> >>>> Given what we have learned, and my own experience >>>> explaining what a Client is, and is not, improving >>>> the definition for Client could prove useful. I am >>>> not suggesting the term be redefined, but clarified. >>>> >>>> For example, clarifying that a Client is a role an >>>> entity plays in the protocol, and that the same >>>> entity may play other roles at other times, or some >>>> other language to help differentiate between "role" >>>> and "entity". >>>> >>>> /Dick >>>> [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ >>>> >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>> >>> >>> >> wrote: >>>> I’m in favor of coming up with a new term that’s a >>>> better fit, but I’m not really in favor of taking >>>> an existing term and applying a completely new >>>> definition to it. In other words, I would sooner >>>> stop using “client” and come up with a new, more >>>> specific and accurate term for the role than to >>>> define “client” as meaning something completely >>>> different. We did this in going from OAuth 1 to >>>> OAuth 2 already, moving from the >>>> even-more-confusing “consumer” to “client”, but >>>> OAuth 2 doesn’t use the term “consumer” at all, nor >>>> does it use “server” on its own but instead always >>>> qualifies it with “Authorization Server” and >>>> “Resource Server”. >>>> >>>> GNAP can do something similar, in my opinion. But >>>> what we can’t do is ignore the fact that GNAP is >>>> going to be coming up in a world that is already >>>> permeated by OAuth 2 and its terminology. We don’t >>>> have a blank slate to work with, but neither are we >>>> bound to use the same terms and constructs as >>>> before. It’s going to be a delicate balance! >>>> >>>>  — Justin >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>>> >>> >>> >> wrote: >>>> >>>> I think that is fundamentally part of the question: >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to >>>> OAuth 2.0, and reusing terms >>>> from OAuth 2.0 but with different definitions may >>>> lead to unnecessary >>>> confusion >>>> >>>> If we say that this document assumes OAuth2.0 >>>> terminology, then we should not change the meanings >>>> of any definition. If we are saying this supersedes >>>> or replaces what OAuth 2.0 creates, then we should >>>> pick the best word for the job and ignore >>>> conflicting meanings from OAuth 2.0. I have a lot >>>> of first hand experience of industries "ruining >>>> words", and attempting to side-step the problem >>>> rather than redefining the word just confuses >>>> everyone as everyone forgets the original meaning >>>> as new documents come out, but the confusion with >>>> the use of a non-obvious word continues. >>>> >>>> Food for thought. >>>> - Warren >>>> >>>> [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA] >>>> >>>> Warren Parad >>>> Founder, CTO >>>> >>>> Secure your user data and complete your >>>> authorization architecture. Implement >>>> Authress.ly/37SSO1p>. >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>> >>> >>> >> wrote: >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a >>>> response similar to the one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there’s still a problem with the >>>> terminology in use here. What >>>> > > you describe as RS2, which might in fact be an >>>> RS unto itself, is a >>>> > > “Client” in OAuth parlance because it is /a >>>> client of RS1/. What you >>>> > > call a “client” has no analogue in the OAuth >>>> world, but it is not at >>>> > > all the same as an OAuth client. I appreciate >>>> your mapping of the >>>> > > entities below, but it makes it difficult to >>>> hold a discussion if we >>>> > > aren’t using the same terms. >>>> > > >>>> > > The good news is that this isn’t OAuth, and as >>>> a new WG we can define >>>> > > our own terms. The bad news is that this is >>>> really hard to do. >>>> > > >>>> > > In GNAP, we shouldn’t just re-use existing >>>> terms with new definitions, >>>> > > but we’ve got a chance to be more precise with >>>> how we define things. >>>> > >>>> > In the ISO context, each document must define its >>>> own terminology. The >>>> > boiler plate for RFCs does not mandate a >>>> terminology or definitions section >>>> > but does not prevent it either. The vocabulary is >>>> limited and as long as >>>> > we clearly define what our terms are meaning, we >>>> can re-use a term already >>>> > used in another RFC. This is also the ISO approach. >>>> >>>> Just because we can do something does not >>>> necessarily mean that it is a >>>> good idea to do so.  We are clear that we are >>>> producing a protocol that is >>>> conceptually (if not more strongly) related to >>>> OAuth 2.0, and reusing terms >>>> from OAuth 2.0 but with different definitions may >>>> lead to unnecessary >>>> confusion.  If I understand correctly, a similar >>>> reasoning prompted Dick to >>>> use the term "GS" in XAuth, picking a name that was >>>> not already used in >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> >>> > >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> >>> > >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> >>> > >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> 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/ >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > 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/ --------------EA071D507A1873194207BB77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Francis,

In the proposed flow, between (2) and (3), there should be a flow for the User Consent. That flow is missing.

In addition, keep in mind that the Resource Controller (RC) can be an application with no end-user involved.
Hence, there is no "consent" from such an application, but only the enforcement of some rules.

I do not see the relationship with the topic raised in that thread which is about User Consent based on information
provided to the User by the RS. If you want to discuss something else, please open a new thread.

Denis
 
Small digest of the consent discussion into the suggested abstract flow. Please do not nail on the words used (just working assumptions).
- GS is used to refer to the token manager (what Justin calls Delegation Server (DS) - handles the back-channel stuff)
- AS is used to refer to the authorization server (what Justin calls Interaction Server (IS) - handles the front-channel stuff)
- (End User), (Client) are sample entities materializing the corresponding roles (in oAuth2 for example)

Added Separation between GS and AS (resp. DS and IS sse above)
- 3a: GS forwards request for the RC consent to an AS, that knows how to interact with the RC
- 3b: AS returns RC consent to GS.
This separation might help draw a line between token management and user authorization. This is essential for forward thinking into the world of Fido, SSI, DID.

Display front channel and back channel (At the Abstraction Level-0 -GNAP, this shall not matter.)
Steps (1, 4, 7) are good candidates for a front channel, as we are interacting with a potential (End User).
Steps (2, 3, 5 , 6) are good candidates for back channel.
Steps (3a, 3b) are candidates for both, as AS might be running on a user device.

Here is the new diagram.

+-----------+      +--------------+  +----+  +----+   +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  |    |   |    |  | Resource Controller |
|           |      |              |  | RS |  | GS |   | AS |  |                     |
|(End User) |      |   (Client)   |  |    |  |    |   |    |  |      (End User)     |
+-----------+      +--------------+  +----+  +----+   +----+  +---------------------+
  |(1) ServiceRequest     |            |       |        |                |
  |---------------------->|            |       |        |                |
  |                       |(2) ServiceIntent:AuthZChallenge              |
  |                       |<---------->|       |        |                |
  |                       |            |       |        |                |
  |                       |(3) AuthZRequest(AuthZChallenge)              |
  |                       |------------------->|        |                |
  |                       |            |       |(3a)ConsentRequest(AuthZChallenge)
  |                       |            |       |------->|                |
  |                       |            |       |        |(4) ConsentRequest:Consent
  |                       |            |       |        |<-------------->|
  |                       |            |       |(3b)UserConsent          |
  |                       |            |       |<-------|                |
  |                       |(5) GrantAccess(AuthZ).      |                |
  |                       |<-------------------|        |                |
  |                       |            |       |        |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse.    |
  |                       |<---------->|       |        |                |
  |(7) ServiceResponse    |            |       |        |                |
  |<----------------------|            |       |        |                |
  +                       +            +       +        +                +

Best regards.
/Francis


On Fri, Aug 14, 2020 at 6:14 AM Denis <denis.ietf@free.fr> wrote:
This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"

Hi Dick,

I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted by a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

Examples of combinations:

condition 1 AND condition 2
condition 1 OR condition 2
(condition 1 AND condition 2) OR condition 3
(condition 1 OR condition 2) AND condition 3

The following notation is being used for the conditions:

condition x = { AS identifier + set of attributes types }

Each RS internally constructs an authorization table with the following content:

1°  For the "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

2°  For any other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

 In many jurisdictions there are regulations regarding what information needs to be conveyed to a user, and potentially a consent requirement,
for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that. 

On a related note, the browsers attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis



ᐧ

On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
Dick,

I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes. 

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.  A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



ᐧ

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It’s a role fulfilled by a person, so I’m not sure where the objection you’re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

 — Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

 - Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto: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/
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


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


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


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


--------------EA071D507A1873194207BB77-- From nobody Fri Aug 14 09:48:08 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 A81543A0E3F for ; Fri, 14 Aug 2020 09:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 N0UTuFp1qykh for ; Fri, 14 Aug 2020 09:48:00 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F643A0E33 for ; Fri, 14 Aug 2020 09:47:59 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d19 with ME id FUnw2300C2bcEcA03UnxFc; Fri, 14 Aug 2020 18:47:57 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 14 Aug 2020 18:47:57 +0200 X-ME-IP: 90.79.51.120 To: Tom Jones Cc: "txauth@ietf.org" References: <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> From: Denis Message-ID: <3f12684f-0354-866c-5700-8a1732dc7394@free.fr> Date: Fri, 14 Aug 2020 18:47:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D61387A41D77C25D1769781B" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] User consent 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: Fri, 14 Aug 2020 16:48:05 -0000 This is a multi-part message in MIME format. --------------D61387A41D77C25D1769781B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tom, I will make a reply similar to the one sent to Francis. You are willing to discuss something else, please open one or two new threads (since there are two new topics). Denis > Here are some proposals that are working their way through other > channels. > 1. on consent grant.: https://wiki.idesg.org/wiki/index.php/Consent_Grant > 2 on delegations: https://wiki.idesg.org/wiki/index.php/Delegation > Comments are welcomed. > Peace ..tom > > > On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha > > > wrote: > > Small digest of the consent discussion into the suggested abstract > flow. Please do not nail on the words used (just working > assumptions). > - GS is used to refer to the token manager (what Justin calls > Delegation Server (DS) - handles the back-channel stuff) > - AS is used to refer to the authorization server (what Justin > calls Interaction Server (IS) - handles the front-channel stuff) > - (End User), (Client) are sample entities materializing the > corresponding roles (in oAuth2 for example) > > Added Separation between GS and AS (resp. DS and IS sse above) > - 3a: GS forwards request for the RC consent to an AS, that knows > how to interact with the RC > - 3b: AS returns RC consent to GS. > This separation might help draw a line between token management > and user authorization. This is essential for forward thinking > into the world of Fido, SSI, DID. > > Display front channel and back channel (At the Abstraction Level-0 > -GNAP, this shall not matter.) > Steps (1, 4, 7) are good candidates for a front channel, as we are > interacting with a potential (End User). > Steps (2, 3, 5 , 6) are good candidates for back channel. > Steps (3a, 3b) are candidates for both, as AS might be running on > a user device. > > Here is the new diagram. > > +-----------+  +--------------+  +----+ >  +----+   +----+  +---------------------+ > | Requestor |      | Orchestrator |  |    |  |    |   |    |  | > Resource Controller | > |           |      |     |  | RS |  | GS |   | AS |  |  | > |(End User) |      |  (Client)   |  |    |  |    |   |    |  |    >   (End User)     | > +-----------+  +--------------+  +----+ >  +----+   +----+  +---------------------+ >   |(1) ServiceRequest     |          |       |        |           >      | >   |---------------------->|            |       |     |             >    | >   |                       |(2) ServiceIntent:AuthZChallenge        >       | >   |                       |<---------->| |        |                | >   |                       |            |       |   |                | >   |                       |(3) AuthZRequest(AuthZChallenge)        >       | >   |                       |------------------->|     |            >     | >   |                       |            | >  |(3a)ConsentRequest(AuthZChallenge) >   |                       |          |       |------->|            >     | >   |                       |          |       |        |(4) > ConsentRequest:Consent >   |                       |            |       |   |<-------------->| >   |                       |            |  |(3b)UserConsent          | >   |                       |            |  |<-------|                | >   |                       |(5) GrantAccess(AuthZ).   |            >     | >   |                       |<-------------------|     |            >     | >   |                       |            |       |   |                | >   |                       |(6) > ServiceRequest(AuthZ):ServiceResponse.    | >   |                       |<---------->|  |        |                | >   |(7) ServiceResponse    |            |       |   |                | >   |<----------------------|            |       |     |            >     | >   +                       +            +       +  +                + > > Best regards. > /Francis > > > On Fri, Aug 14, 2020 at 6:14 AM Denis > wrote: > > This is a new thread built from "Revisiting the photo sharing > example (a driving use case for the creation of OAuth)" > > Hi Dick, > >> I don't see how we can technically standardize a user >> experience, and it is not clear why a standard would be >> needed for interoperability. > > I already wrote a proposal and made it available to the > mailing list. > > An access will be granted by a RS based on an mathematical > expression which is formed using some combination of ANDand OR > conditions. > > Examples of combinations: > > /condition 1/AND/condition 2 > condition 1/OR /condition 2/ > (/condition 1/AND/condition 2)/OR/condition 3 > (condition 1/OR /condition 2)/AND/condition 3/ > > The following notation is being used for the /conditions/: > > /condition x/= { AS identifier + set of attributes types } > > Each RS internally constructs an /authorization table/ with > the following content: > > 1°For the "authentication" operation: either FIDO U2For a > mathematical expression using conditions; > > 2°For any other operation: a mathematical expression using > conditions. > > Given the operation selected by the client, the RS returns the > appropriate mathematical expression and only the associated > conditions > used in that mathematical expression. The User may then decide > whether they are appropriate to him or not. > >>  In many jurisdictions there are regulations regarding what >> information needs to be conveyed to a user, and potentially a >> consent requirement, >> for example a site explaining its use of cookies -- but I >> don't see how IETF would play a role in that. >> >> On a related note, the browsers attempted to standardize the >> username / password prompt, and that has been rejected by >> pretty much every site. >> The only site I've visited in the last decade that has used >> the browsers' built in username / password prompt was the W3C >> site -- and it was a frustrating >> experience since there was no button for account recovery -- >> it would just keep popping up. > > What I am proposing is unrelated to the two above cases you > mention. > > Denis > >> >> >> ᐧ >> >> On Thu, Aug 13, 2020 at 10:29 AM Denis > > wrote: >> >> Dick, >> >>> I think Tom's objection, and I agree with it, is that >>> humans don't interact in bits and bytes. >>> >>> I think it is useful to separate human interactions with >>> software from software interactions with software. >>> The latter we can standardize, the former we can call >>> out as part of the overall process, but it is not something >>> that is testable or required for interop, so I would >>> argue human to software interactions are NOT part of the >>> protocol. >> >> I disagree.  A set of a choices should be presented by >> the RS to the Client in a standardized way. The choices >> made by the user >> should be locally recorded by the Client, hence the RS >> does not need to be informed of these choices. The RS >> will only know >> the end result of these choices when/if it gets back one >> or more access tokens. >> >> Human to software interactions should be part of the >> protocol. >> >> RS to Client: a set of choices >> >> Client to RS: Done (choices have been done by the user). >> >> Denis >> >> >>> >>> ᐧ >>> >>> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer >>> > wrote: >>> >>> It’s a role fulfilled by a person, so I’m not sure >>> where the objection you’re raising comes from. >>> >>> Also, whatever roles we define here, whether >>> software or human-ware, they need to be related to >>> the protocol. >>> >>>  — Justin >>> >>>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>>> >>> > wrote: >>>> >>>> I strong object to the objectification of human >>>> users. It is way past time that the IETF becaume >>>> user oriented instead of web service oriented. >>>> users are human in my language. >>>> Peace ..tom >>>> >>>> >>>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer >>>> > wrote: >>>> >>>> If defined as the party operating the client >>>> software, then the user is a role. I believe >>>> this is more accurate and inclusive than the >>>> definition you have proposed with the user as >>>> an entity. >>>> >>>>  - Justin >>>> ________________________________________ >>>> From: Dick Hardt [dick.hardt@gmail.com >>>> ] >>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>> To: Francis Pouatcha >>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; >>>> txauth@ietf.org >>>> Subject: Re: [GNAP] [Txauth] Revisiting the >>>> photo sharing example (a driving use case for >>>> the creation of OAuth) >>>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the >>>> protocol in how I am defining roles, so steps >>>> (1) and (7) are confusing to me on what is >>>> happening. >>>> >>>> I also think that (2) could be an extension to >>>> GNAP, rather than part of the core protocol. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 10, 2020 at 8:04 PM Francis >>>> Pouatcha >>> >>> >> wrote: >>>> In this context, I suggest we pick some words >>>> to work with, and sharpen them as we move on, >>>> discover and map new use cases to the protocol. >>>> >>>> In this diagram from the original thread >>>> (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), >>>> I replaced the words: >>>> >>>> +-----------+ +--------------+ +----+  +----+ >>>> +---------------------+ >>>> | Requestor |      | Orchestrator |  |    | | >>>> GS |  | Resource Controller | >>>> |   was     |      |  was      |  | RS |  | or >>>> |  |         was    | >>>> |  User     |      |  Client     |  |    |  | >>>> AS |  |    Resource Owner   | >>>> +-----------+ +--------------+ +----+  +----+ >>>> +---------------------+ >>>>   |(1) ServiceRequest  |            |       |   >>>>             | >>>> |---------------------->|           |       |   >>>>         | >>>>   |  |(2) ServiceIntent:AuthZChallenge    | >>>>   |  |<---------->|    |                | >>>>   |  |            |       |               | >>>>   |  |(3) AuthZRequest(AuthZChallenge)    | >>>>   |  |------------------->|                | >>>>   |  |            |  |(4) ConsentRequest:Grant >>>>   |  |            |  |<-------------->| >>>>   |  |(5) GrantAccess(AuthZ)          | >>>>   |  |<-------------------|                | >>>>   |  |            |       |               | >>>>   |  |(6) ServiceRequest(AuthZ):ServiceResponse >>>>   |  |<---------->|    |                | >>>>   |(7) ServiceResponse   |            |  |      >>>>           | >>>> |<----------------------|           |       |   >>>>         | >>>>   +  +            +       +               + >>>> >>>> The purpose of the GNAP protocol is to help >>>> negotiate access to a protected resource. It >>>> starts with a requestor delegating activity to >>>> an orchestrator. These are all roles, no >>>> entities. Let focus on mapping the use cases to >>>> the protocol roles and interactions so wwe can >>>> discover what is missing. >>>> >>>> It seems cumbersome to use it in discussions as >>>> it is impossible to give the word "Client" a >>>> clear definition. >>>> >>>> We can mention in the final document, that the >>>> "Orchestrator" (or whatever word we finally >>>> use) plays the same role as the "Client" in oAuth2. >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>>> >>> >>> >> wrote: >>>> I agree with Justin. Redefining well used terms >>>> will lead to significant confusion. If we have >>>> a different role than what we have had in the >>>> past, then that role should have a name not >>>> being used already in OAuth or OIDC. >>>> >>>> Given what we have learned, and my own >>>> experience explaining what a Client is, and is >>>> not, improving the definition for Client could >>>> prove useful. I am not suggesting the term be >>>> redefined, but clarified. >>>> >>>> For example, clarifying that a Client is a role >>>> an entity plays in the protocol, and that the >>>> same entity may play other roles at other >>>> times, or some other language to help >>>> differentiate between "role" and "entity". >>>> >>>> /Dick >>>> [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ >>>> >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>> >>> >>> >> wrote: >>>> I’m in favor of coming up with a new term >>>> that’s a better fit, but I’m not really in >>>> favor of taking an existing term and applying a >>>> completely new definition to it. In other >>>> words, I would sooner stop using “client” and >>>> come up with a new, more specific and accurate >>>> term for the role than to define “client” as >>>> meaning something completely different. We did >>>> this in going from OAuth 1 to OAuth 2 already, >>>> moving from the even-more-confusing “consumer” >>>> to “client”, but OAuth 2 doesn’t use the term >>>> “consumer” at all, nor does it use “server” on >>>> its own but instead always qualifies it with >>>> “Authorization Server” and “Resource Server”. >>>> >>>> GNAP can do something similar, in my opinion. >>>> But what we can’t do is ignore the fact that >>>> GNAP is going to be coming up in a world that >>>> is already permeated  by OAuth 2 and its >>>> terminology. We don’t have a blank slate to >>>> work with, but neither are we bound to use the >>>> same terms and constructs as before. It’s going >>>> to be a delicate balance! >>>> >>>>  — Justin >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>>> >>> >>> >> wrote: >>>> >>>> I think that is fundamentally part of the question: >>>> We are clear that we are producing a protocol >>>> that is >>>> conceptually (if not more strongly) related to >>>> OAuth 2.0, and reusing terms >>>> from OAuth 2.0 but with different definitions >>>> may lead to unnecessary >>>> confusion >>>> >>>> If we say that this document assumes OAuth2.0 >>>> terminology, then we should not change the >>>> meanings of any definition. If we are saying >>>> this supersedes or replaces what OAuth 2.0 >>>> creates, then we should pick the best word for >>>> the job and ignore conflicting meanings from >>>> OAuth 2.0. I have a lot of first hand >>>> experience of industries "ruining words", and >>>> attempting to side-step the problem rather than >>>> redefining the word just confuses everyone as >>>> everyone forgets the original meaning as new >>>> documents come out, but the confusion with the >>>> use of a non-obvious word continues. >>>> >>>> Food for thought. >>>> - Warren >>>> >>>> [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA] >>>> >>>> Warren Parad >>>> Founder, CTO >>>> >>>> Secure your user data and complete your >>>> authorization architecture. Implement >>>> Authress.ly/37SSO1p>. >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>> >>> >>> >> wrote: >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis >>>> wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a >>>> response similar to the one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there’s still a problem with the >>>> terminology in use here. What >>>> > > you describe as RS2, which might in fact be >>>> an RS unto itself, is a >>>> > > “Client” in OAuth parlance because it is /a >>>> client of RS1/. What you >>>> > > call a “client” has no analogue in the >>>> OAuth world, but it is not at >>>> > > all the same as an OAuth client. I >>>> appreciate your mapping of the >>>> > > entities below, but it makes it difficult >>>> to hold a discussion if we >>>> > > aren’t using the same terms. >>>> > > >>>> > > The good news is that this isn’t OAuth, and >>>> as a new WG we can define >>>> > > our own terms. The bad news is that this is >>>> really hard to do. >>>> > > >>>> > > In GNAP, we shouldn’t just re-use existing >>>> terms with new definitions, >>>> > > but we’ve got a chance to be more precise >>>> with how we define things. >>>> > >>>> > In the ISO context, each document must define >>>> its own terminology. The >>>> > boiler plate for RFCs does not mandate a >>>> terminology or definitions section >>>> > but does not prevent it either. The >>>> vocabulary is limited and as long as >>>> > we clearly define what our terms are meaning, >>>> we can re-use a term already >>>> > used in another RFC. This is also the ISO >>>> approach. >>>> >>>> Just because we can do something does not >>>> necessarily mean that it is a >>>> good idea to do so.  We are clear that we are >>>> producing a protocol that is >>>> conceptually (if not more strongly) related to >>>> OAuth 2.0, and reusing terms >>>> from OAuth 2.0 but with different definitions >>>> may lead to unnecessary >>>> confusion.  If I understand correctly, a >>>> similar reasoning prompted Dick to >>>> use the term "GS" in XAuth, picking a name that >>>> was not already used in >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> >>> > >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> >>> > >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> >>> > >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> 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/ >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------D61387A41D77C25D1769781B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Tom,

I will make a reply similar to the one sent to Francis.

You are willing to discuss something else, please open one or two new threads (since there are two new topics).

Denis

Here are some proposals that are working their way through other channels.
Comments are welcomed.
Peace ..tom


On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org> wrote:
Small digest of the consent discussion into the suggested abstract flow. Please do not nail on the words used (just working assumptions).
- GS is used to refer to the token manager (what Justin calls Delegation Server (DS) - handles the back-channel stuff)
- AS is used to refer to the authorization server (what Justin calls Interaction Server (IS) - handles the front-channel stuff)
- (End User), (Client) are sample entities materializing the corresponding roles (in oAuth2 for example)

Added Separation between GS and AS (resp. DS and IS sse above)
- 3a: GS forwards request for the RC consent to an AS, that knows how to interact with the RC
- 3b: AS returns RC consent to GS.
This separation might help draw a line between token management and user authorization. This is essential for forward thinking into the world of Fido, SSI, DID.

Display front channel and back channel (At the Abstraction Level-0 -GNAP, this shall not matter.)
Steps (1, 4, 7) are good candidates for a front channel, as we are interacting with a potential (End User).
Steps (2, 3, 5 , 6) are good candidates for back channel.
Steps (3a, 3b) are candidates for both, as AS might be running on a user device.

Here is the new diagram.

+-----------+      +--------------+  +----+  +----+   +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  |    |   |    |  | Resource Controller |
|           |      |              |  | RS |  | GS |   | AS |  |                     |
|(End User) |      |   (Client)   |  |    |  |    |   |    |  |      (End User)     |
+-----------+      +--------------+  +----+  +----+   +----+  +---------------------+
  |(1) ServiceRequest     |            |       |        |                |
  |---------------------->|            |       |        |                |
  |                       |(2) ServiceIntent:AuthZChallenge              |
  |                       |<---------->|       |        |                |
  |                       |            |       |        |                |
  |                       |(3) AuthZRequest(AuthZChallenge)              |
  |                       |------------------->|        |                |
  |                       |            |       |(3a)ConsentRequest(AuthZChallenge)
  |                       |            |       |------->|                |
  |                       |            |       |        |(4) ConsentRequest:Consent
  |                       |            |       |        |<-------------->|
  |                       |            |       |(3b)UserConsent          |
  |                       |            |       |<-------|                |
  |                       |(5) GrantAccess(AuthZ).      |                |
  |                       |<-------------------|        |                |
  |                       |            |       |        |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse.    |
  |                       |<---------->|       |        |                |
  |(7) ServiceResponse    |            |       |        |                |
  |<----------------------|            |       |        |                |
  +                       +            +       +        +                +

Best regards.
/Francis


On Fri, Aug 14, 2020 at 6:14 AM Denis <denis.ietf@free.fr> wrote:
This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"

Hi Dick,

I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted by a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

Examples of combinations:

condition 1 AND condition 2
condition 1 OR condition 2
(condition 1 AND condition 2) OR condition 3
(condition 1 OR condition 2) AND condition 3

The following notation is being used for the conditions:

condition x = { AS identifier + set of attributes types }

Each RS internally constructs an authorization table with the following content:

1°  For the "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

2°  For any other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

 In many jurisdictions there are regulations regarding what information needs to be conveyed to a user, and potentially a consent requirement,
for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that. 

On a related note, the browsers attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis



ᐧ

On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
Dick,

I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes. 

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.  A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



ᐧ

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It’s a role fulfilled by a person, so I’m not sure where the objection you’re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

 — Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

 - Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>.


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there’s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > “Client” in OAuth parlance because it is /a client of RS1/. What you
> > call a “client” has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren’t using the same terms.
> >
> > The good news is that this isn’t OAuth, and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn’t just re-use existing terms with new definitions,
> > but we’ve got a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto: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/
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


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


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


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


--------------D61387A41D77C25D1769781B-- From nobody Fri Aug 14 10:03:51 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 4EF403A0E3F for ; Fri, 14 Aug 2020 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 (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 9kmeBH72S60n for ; Fri, 14 Aug 2020 10:03:46 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 DAB6D3A0B31 for ; Fri, 14 Aug 2020 10:03:45 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id k8so8507010wma.2 for ; Fri, 14 Aug 2020 10:03:45 -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=YIg4MjxhV7V3MPZNEcD4bMPJVQA4o7v/w7fs2jA2iLs=; b=H8eO4usOIny2bVTWKhNlr61GGWXOthNr0CWYdj/cmt4TzfvAim3qa1qHT6S7/Jn5QN 928HDXH9PBMscDU56yr++pc+7+HIB+EJsDV5iyARL5tXgkX0AaR1jrnlYXVzAT7ZGmNH dLeZGf5fAuKW0kgJRJsO8DVCGfYsY0PVeDFRw= 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=YIg4MjxhV7V3MPZNEcD4bMPJVQA4o7v/w7fs2jA2iLs=; b=ieoM0nCh9dpgvprsSSm+6dPCO/ysTbIMrp8sGh98lAUpWLx8wy+j7uI/XO35E8LUtp mBvYistdthntfCoN7YDcHMQqTgp/NiV+xYip/kIWPuaZoWD1KOGhB9D+pgEwrdgcVx3i vDzHZrhbVxlZuDpa0loZqvau/4r4GzcmzLSFl6+koUU8JDjPxxNKwODQtw6ABjl6Wozp MK2fPvgdBQ0dqfH6nzdLJQwZfC/yyFicWsmghELcfq5qRtp90U5I/QX70JJ5tmNXXIqn Xx9kRWtrUgpCXUmaoWAPhPzHIAUiKWy/9Y3D5eQEoEu1k/oFmY8O/0U9Zm1XZSYRr5Xe z5fA== X-Gm-Message-State: AOAM532eX4dNIISKfPJfTTkqWy7SSIV6aOYrI2LAUnNq50BNcmtYvVK4 Nnug7mekiejFKCRnSQHq45UI8+uBq4C1+zBZSa7OYw== X-Google-Smtp-Source: ABdhPJx1C0yP30pYpRk9uFxL/T1kIFi0qc5a8hTfZFL8F3q7O+URBMDJvFkl2p4/QZrXDRcJ1Gis/NbOlL9rPRKcGSM= X-Received: by 2002:a1c:770c:: with SMTP id t12mr3552037wmi.65.1597424624074; Fri, 14 Aug 2020 10:03:44 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> In-Reply-To: From: Francis Pouatcha Date: Fri, 14 Aug 2020 13:03:31 -0400 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046193205acd96706" Archived-At: Subject: Re: [GNAP] User consent 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: Fri, 14 Aug 2020 17:03:49 -0000 --00000000000046193205acd96706 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, On Fri, Aug 14, 2020 at 12:39 PM Denis wrote: > Hi Francis, > > In the proposed flow, between (2) and (3), there should be a flow for the > User Consent. That flow is missing. > What User? (End User -> Requestor) or (End User -> Resource Controller)? What if both are not the same party? > > In addition, keep in mind that the Resource Controller (RC) can be an > application with no end-user involved. > Hence, there is no "consent" from such an application, but only the > enforcement of some rules. > Means you are obtaining the consent from an "End User" in his role as a "Requestor" of the service? What do you need this consent for? > I do not see the relationship with the topic raised in that thread which > is about User Consent based on information > provided to the User by the RS. If you want to discuss something else, > please open a new thread. > NO! Correct thread! Without the diagram, there is no way the reader can figure out what is being discussed here. /Francis > > Denis > > > Small digest of the consent discussion into the suggested abstract flow. > Please do not nail on the words used (just working assumptions). > - GS is used to refer to the token manager (what Justin calls Delegation > Server (DS) - handles the back-channel stuff) > - AS is used to refer to the authorization server (what Justin calls > Interaction Server (IS) - handles the front-channel stuff) > - (End User), (Client) are sample entities materializing the correspondin= g > roles (in oAuth2 for example) > > Added Separation between GS and AS (resp. DS and IS sse above) > - 3a: GS forwards request for the RC consent to an AS, that knows how to > interact with the RC > - 3b: AS returns RC consent to GS. > This separation might help draw a line between token management and user > authorization. This is essential for forward thinking into the world of > Fido, SSI, DID. > > Display front channel and back channel (At the Abstraction Level-0 -GNAP, > this shall not matter.) > Steps (1, 4, 7) are good candidates for a front channel, as we are > interacting with a potential (End User). > Steps (2, 3, 5 , 6) are good candidates for back channel. > Steps (3a, 3b) are candidates for both, as AS might be running on a user > device. > > Here is the new diagram. > > +-----------+ +--------------+ +----+ > +----+ +----+ +---------------------+ > | Requestor | | Orchestrator | | | | | | | | Resource > Controller | > | | | | | RS | | GS | | AS | | > | > |(End User) | | (Client) | | | | | | | | (End > User) | > +-----------+ +--------------+ +----+ > +----+ +----+ +---------------------+ > |(1) ServiceRequest | | | | = | > |---------------------->| | | | = | > | |(2) ServiceIntent:AuthZChallenge = | > | |<---------->| | | = | > | | | | | = | > | |(3) AuthZRequest(AuthZChallenge) = | > | |------------------->| | = | > | | | > |(3a)ConsentRequest(AuthZChallenge) > | | | |------->| = | > | | | | |(4) > ConsentRequest:Consent > | | | | |<-------------->= | > | | | |(3b)UserConsent = | > | | | |<-------| = | > | |(5) GrantAccess(AuthZ). | = | > | |<-------------------| | = | > | | | | | = | > | |(6) ServiceRequest(AuthZ):ServiceResponse. = | > | |<---------->| | | = | > |(7) ServiceResponse | | | | = | > |<----------------------| | | | = | > + + + + + = + > > Best regards. > /Francis > > > On Fri, Aug 14, 2020 at 6:14 AM Denis wrote: > >> This is a new thread built from "Revisiting the photo sharing example (a >> driving use case for the creation of OAuth)" >> >> Hi Dick, >> >> I don't see how we can technically standardize a user experience, and it >> is not clear why a standard would be needed for interoperability. >> >> I already wrote a proposal and made it available to the mailing list. >> >> An access will be granted by a RS based on an mathematical expression >> which is formed using some combination of AND and OR conditions. >> >> Examples of combinations: >> >> *condition 1* AND >> *condition 2 condition 1* OR *condition 2* >> (*condition 1* AND *condition 2)* OR >> *condition 3 (condition 1* OR *condition 2)* AND *condition 3* >> >> The following notation is being used for the *conditions*: >> >> *condition x* =3D { AS identifier + set of attributes types } >> >> Each RS internally constructs an *authorization table* with the >> following content: >> >> 1=C2=B0 For the "authentication" operation: either FIDO U2F or a >> mathematical expression using conditions; >> >> 2=C2=B0 For any other operation: a mathematical expression using condit= ions. >> >> Given the operation selected by the client, the RS returns the >> appropriate mathematical expression and only the associated conditions >> used in that mathematical expression. The User may then decide whether >> they are appropriate to him or not. >> >> In many jurisdictions there are regulations regarding what information >> needs to be conveyed to a user, and potentially a consent requirement, >> for example a site explaining its use of cookies -- but I don't see how >> IETF would play a role in that. >> >> On a related note, the browsers attempted to standardize the username / >> password prompt, and that has been rejected by pretty much every site. >> The only site I've visited in the last decade that has used the browsers= ' >> built in username / password prompt was the W3C site -- and it was a >> frustrating >> experience since there was no button for account recovery -- it would >> just keep popping up. >> >> What I am proposing is unrelated to the two above cases you mention. >> >> Denis >> >> >> >> =E1=90=A7 >> >> On Thu, Aug 13, 2020 at 10:29 AM Denis wrote: >> >>> Dick, >>> >>> I think Tom's objection, and I agree with it, is that humans don't >>> interact in bits and bytes. >>> >>> I think it is useful to separate human interactions with software from >>> software interactions with software. >>> The latter we can standardize, the former we can call out as part of th= e >>> overall process, but it is not something >>> that is testable or required for interop, so I would argue human to >>> software interactions are NOT part of the protocol. >>> >>> I disagree. A set of a choices should be presented by the RS to the >>> Client in a standardized way. The choices made by the user >>> should be locally recorded by the Client, hence the RS does not need to >>> be informed of these choices. The RS will only know >>> the end result of these choices when/if it gets back one or more access >>> tokens. >>> >>> Human to software interactions should be part of the protocol. >>> >>> RS to Client: a set of choices >>> >>> Client to RS: Done (choices have been done by the user). >>> >>> Denis >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: >>> >>>> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure whe= re the objection >>>> you=E2=80=99re raising comes from. >>>> >>>> Also, whatever roles we define here, whether software or human-ware, >>>> they need to be related to the protocol. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>>> wrote: >>>> >>>> I strong object to the objectification of human users. It is way past >>>> time that the IETF becaume user oriented instead of web service orient= ed. >>>> users are human in my language. >>>> Peace ..tom >>>> >>>> >>>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >>>> >>>>> If defined as the party operating the client software, then the user >>>>> is a role. I believe this is more accurate and inclusive than the >>>>> definition you have proposed with the user as an entity. >>>>> >>>>> - Justin >>>>> ________________________________________ >>>>> From: Dick Hardt [dick.hardt@gmail.com] >>>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>>> To: Francis Pouatcha >>>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>>>> driving use case for the creation of OAuth) >>>>> >>>>> Hi Francis >>>>> >>>>> The user is an entity, not a role in the protocol in how I am definin= g >>>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>>> >>>>> I also think that (2) could be an extension to GNAP, rather than part >>>>> of the core protocol. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>>> > wrote: >>>>> In this context, I suggest we pick some words to work with, and >>>>> sharpen them as we move on, discover and map new use cases to the pro= tocol. >>>>> >>>>> In this diagram from the original thread ( >>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JO= GNw/), >>>>> I replaced the words: >>>>> >>>>> +-----------+ +--------------+ +----+ +----+ >>>>> +---------------------+ >>>>> | Requestor | | Orchestrator | | | | GS | | Resource >>>>> Controller | >>>>> | was | | was | | RS | | or | | was >>>>> | >>>>> | User | | Client | | | | AS | | Resource >>>>> Owner | >>>>> +-----------+ +--------------+ +----+ +----+ >>>>> +---------------------+ >>>>> |(1) ServiceRequest | | | | >>>>> |---------------------->| | | | >>>>> | |(2) ServiceIntent:AuthZChallenge | >>>>> | |<---------->| | | >>>>> | | | | | >>>>> | |(3) AuthZRequest(AuthZChallenge) | >>>>> | |------------------->| | >>>>> | | | |(4) >>>>> ConsentRequest:Grant >>>>> | | | |<-------------->| >>>>> | |(5) GrantAccess(AuthZ) | >>>>> | |<-------------------| | >>>>> | | | | | >>>>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>>>> | |<---------->| | | >>>>> |(7) ServiceResponse | | | | >>>>> |<----------------------| | | | >>>>> + + + + + >>>>> >>>>> The purpose of the GNAP protocol is to help negotiate access to a >>>>> protected resource. It starts with a requestor delegating activity to= an >>>>> orchestrator. These are all roles, no entities. Let focus on mapping = the >>>>> use cases to the protocol roles and interactions so wwe can discover = what >>>>> is missing. >>>>> >>>>> It seems cumbersome to use it in discussions as it is impossible to >>>>> give the word "Client" a clear definition. >>>>> >>>>> We can mention in the final document, that the "Orchestrator" (or >>>>> whatever word we finally use) plays the same role as the "Client" in = oAuth2. >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>>> > wrote: >>>>> I agree with Justin. Redefining well used terms will lead to >>>>> significant confusion. If we have a different role than what we have = had in >>>>> the past, then that role should have a name not being used already in= OAuth >>>>> or OIDC. >>>>> >>>>> Given what we have learned, and my own experience explaining what a >>>>> Client is, and is not, improving the definition for Client could prov= e >>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>> >>>>> For example, clarifying that a Client is a role an entity plays in th= e >>>>> protocol, and that the same entity may play other roles at other time= s, or >>>>> some other language to help differentiate between "role" and "entity"= . >>>>> >>>>> /Dick >>>>> [ >>>>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb2= 0%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90= =A7 >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>> jricher@mit.edu>> wrote: >>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a be= tter fit, but I=E2=80=99m >>>>> not really in favor of taking an existing term and applying a complet= ely >>>>> new definition to it. In other words, I would sooner stop using =E2= =80=9Cclient=E2=80=9D >>>>> and come up with a new, more specific and accurate term for the role = than >>>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely di= fferent. We did this >>>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserv= er=E2=80=9D on its own but instead >>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>> >>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>> ignore the fact that GNAP is going to be coming up in a world that is >>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t h= ave a blank >>>>> slate to work with, but neither are we bound to use the same terms an= d >>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>>> wparad@rhosys.ch>> wrote: >>>>> >>>>> I think that is fundamentally part of the question: >>>>> We are clear that we are producing a protocol that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion >>>>> >>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>> should not change the meanings of any definition. If we are saying th= is >>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick th= e best >>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I ha= ve a >>>>> lot of first hand experience of industries "ruining words", and attem= pting >>>>> to side-step the problem rather than redefining the word just confuse= s >>>>> everyone as everyone forgets the original meaning as new documents co= me >>>>> out, but the confusion with the use of a non-obvious word continues. >>>>> >>>>> Food for thought. >>>>> - Warren >>>>> >>>>> [ >>>>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdf= ZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6h= juIm9GCeBRRzrSc8kWcUSNtuA >>>>> ] >>>>> >>>>> Warren Parad >>>>> Founder, CTO >>>>> >>>>> Secure your user data and complete your authorization architecture. >>>>> Implement Authress. >>>>> >>>>> >>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>> kaduk@mit.edu>> wrote: >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a response similar to th= e >>>>> one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there=E2=80=99s still a problem with the terminology in u= se here. >>>>> What >>>>> > > you describe as RS2, which might in fact be an RS unto itself, is= a >>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What >>>>> you >>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not >>>>> at >>>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>>> > > entities below, but it makes it difficult to hold a discussion if >>>>> we >>>>> > > aren=E2=80=99t using the same terms. >>>>> > > >>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can >>>>> define >>>>> > > our own terms. The bad news is that this is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>>> definitions, >>>>> > > but we=E2=80=99ve got a chance to be more precise with how we def= ine >>>>> things. >>>>> > >>>>> > In the ISO context, each document must define its own terminology. >>>>> The >>>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>>> section >>>>> > but does not prevent it either. The vocabulary is limited and as >>>>> long as >>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>> already >>>>> > used in another RFC. This is also the ISO approach. >>>>> >>>>> Just because we can do something does not necessarily mean that it is= a >>>>> good idea to do so. We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>> Dick to >>>>> use the term "GS" in XAuth, picking a name that was not already used = in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> 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/ >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- >> 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/ > > > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --00000000000046193205acd96706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,

=
On Fri= , Aug 14, 2020 at 12:39 PM Denis <= denis.ietf@free.fr> wrote:
=20 =20 =20
Hi Francis,

In the proposed flow, between (2) and (3), there should be a flow for the User Consent. That flow is missing.
What User? (End User -> = Requestor) or (End User -> Resource Controller)? What if both are not th= e same party?
<= div>

In addition, keep in mind that the Resource Controller (RC) can be an application with no end-user involved.
Hence, there is no "consent" from such an application, but = only the enforcement of some rules.
Means= you are obtaining the consent from an "End User" in his role as = a "Requestor" of the service? What do you need this consent for?<= /div>

=

I do not see the relationship with the topic raised in that thread which is about User Consent based on information
provided to the User by the RS. If you want to discuss something else, please open a new thread.
NO! Corr= ect thread! Without the diagram, there is no way the reader can figure out = what is being discussed here.=C2=A0

/Francis
=

Denis
=C2=A0
=20
Small digest of the consent discussion into the suggested abstract flow. Please do not nail on the words used (just working assumptions).
- GS is used to refer to the token manager (what Justin calls Delegation Server (DS) - handles the back-channel stuff)
- AS is used to refer=C2=A0to the authorization server=C2=A0(w= hat Justin calls Interaction Server (IS) - handles the front-channel stuff)
- (End User), (Client) are sample entities materializing the corresponding roles (in oAuth2 for example)

Added Separation between GS and AS (resp. DS and IS sse above)
- 3a: GS forwards request for the RC consent to an AS, that knows how to interact with the RC
- 3b: AS returns RC consent to GS.
This separation might help draw a line between token management and user authorization. This is essential for forward thinking into the world of Fido, SSI, DID.

Display front channel and back channel (At the Abstraction Level-0 -GNAP, this shall not matter.)
Steps (1, 4, 7) are good candidates for a front channel, as we are interacting with a potential (End User).
Steps (2, 3, 5 , 6) are good candidates for back channel.
Steps (3a, 3b) are candidates for both, as AS might be running on a user device.

Here is the new diagram.

+-----------+ =C2=A0 =C2=A0 =C2=A0+--------------+ =C2=A0+----+ =C2=A0+----+=C2=A0=C2=A0=C2=A0+----+=C2=A0=C2=A0+------------= ---------+
| Requestor | =C2=A0 =C2=A0 =C2=A0|= Orchestrator | =C2=A0| =C2=A0 =C2=A0| =C2=A0|=C2=A0 =C2=A0 |=C2=A0=C2=A0= =C2=A0|=C2=A0 =C2=A0 |=C2=A0=C2=A0| Resource Controller |
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0| RS | =C2=A0| GS |=C2=A0=C2=A0=C2=A0| 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|
|(End User) | =C2=A0 =C2=A0 =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 =C2=A0 (End User)=C2=A0 = =C2=A0 =C2=A0|
+-----------+ =C2=A0 =C2=A0 =C2=A0+--------------+ =C2=A0+----+ =C2=A0+----+=C2=A0=C2=A0=C2=A0+----+=C2=A0=C2=A0+------------= ---------+
=C2=A0 |(1) ServiceRequest =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0|=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 |---------------------->| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |(2) ServiceIntent:AuthZChallenge=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |<---------->| =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0|(3a)ConsentRequest(AuthZChallenge)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|------->|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =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) ConsentRequest:Consent
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------->|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0|(3b)UserConsent=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0|<-------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=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) GrantAccess(AuthZ).=C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |<-------------------|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |(6) ServiceRequest(AuthZ):ServiceResponse.=C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |<---------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |
=C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2= =A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 +

Best regards.
/Francis


On Fri, Aug 14, 2020 at 6:14 AM Denis <denis.ietf@free.fr> wrote:
This is a new thread built from "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"

Hi Dick,

I don't see how we = can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted by a RS based on an mathematical expression which is formed using some combination of AND <= /span>and OR conditions.

Examples of combinations:

condition 1 = AND condition 2
condition 1 OR = condition 2
(condition 1 AND condition 2) <= /span>OR conditio= n 3
(condition 1 OR condition 2) AND<= /span> condition 3

The following notation is being used for the conditions:

condition x =3D { AS identifier + set of attributes types }

Each RS internally constructs an authorization table with the following content:

1=C2=B0=C2=A0 For the "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

2=C2=B0=C2=A0 For any other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

=C2=A0In many jurisdictions there are regulations regarding what information needs to be conveyed to a user, and potentially a consent requirement,
for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that.= =C2=A0

On a related note, the browsers=C2=A0attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
The only site I've visited in the last decade that ha= s used the browsers' built in username / password promp= t was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis



3D""=E1=90=A7

On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
Dick,

I think Tom's objection, and I agree with it, is that humans don't interact in bits and bytes.=C2=A0

I think it is useful to separate human interactions with software from software interactions with software.
The latter we can standardize, the former we can call out as part of the overall process, but it is not something
that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

I disagree.=C2=A0 A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access tokens.

Human to software interactions should be part of the protocol.

RS to Client: a set of choices

Client to RS: Done (choices have been done by the user).

Denis



3D""=E1=90=A7

On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
It=E2=80=99s a role fulfilled by a person, s= o I=E2=80=99m not sure where the objection you=E2=80=99re rai= sing comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

=C2=A0=E2=80=94 Justin

On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom


On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

=C2=A0- Justin
________________________________________
From: Dick Hardt [dick.hardt@gmail.com]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:<= a href=3D"mailto:fpo@adorsys.de" target=3D"_blank">fpo@adorsys.de>&g= t; wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txa= uth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

+-----------+=C2=A0 =C2=A0 =C2= =A0 +--------------+=C2=A0 +----+= =C2=A0 +----+=C2=A0 +---------------------+
| Requestor |=C2=A0 =C2=A0 =C2= =A0 | Orchestrator |=C2=A0 |=C2=A0 = =C2=A0 |=C2=A0 | GS |=C2=A0 | Resource Controller |=
|=C2=A0 =C2=A0was=C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |= =C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
|=C2=A0 User=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2= =A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |=C2=A0 =C2=A0 Resource= Owner=C2=A0 =C2=A0|
+-----------+=C2=A0 =C2=A0 =C2= =A0 +--------------+=C2=A0 +----+= =C2=A0 +----+=C2=A0 +---------------------+
=C2=A0 |(1) ServiceRequest=C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2= =A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2= =A0 =C2=A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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) ConsentRequest: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 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =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|(5) GrantAccess(AuthZ)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------------|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceRe= sponse
=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |(7) ServiceResponse=C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear defi= nition.

We can mention in the final document, that the "Orchestrator" (or wh= atever word we finally use) plays the same role as the "Client" in oAuth2.
Best regards.
/Francis





On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<ma= ilto:dick.hardt@g= mail.com>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "rol= e" and "entity".

/Dick
[https://mailfoogae.appspot.com/t?sender=3DaZGljay5o= YXJkdEBnbWFpbC5jb20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c= -8654-d50e00dbac3a]=E1=90=A7

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:= jricher@mit.edu>= ;> wrote:
I=E2=80=99m in favor of coming = up with a new term that=E2=80=99s = a better fit, but I=E2=80=99m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclie= nt=E2=80=9D and come up with a new, more specific and accurate term for the role than to define =E2=80=9Cclient=E2=80=9D as mea= ning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to = =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the= term =E2=80=9Cconsumer=E2=80=9D at a= ll, nor does it use =E2=80=9Cserver=E2=80=9D= on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and =E2=80=9CRe= source Server=E2=80=9D.

GNAP can do something similar, in my opinion. But what we can=E2=80=99t do is ign= ore the fact that GNAP is going to be coming up in a world that is already permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t h= ave a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2=80= =99s going to be a delicate balance!

=C2=A0=E2=80=94 Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>&= gt; wrote:

I think that is fundamentally part of the question:
We are clear that we are producing a protocol that is conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion

If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DN= iDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBha= ZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>= .


On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
Hi Denis,

On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
> Hi Justin,
>
> Since you replied in parallel, I will make a response similar to the one
> I sent to Dick.
>
> > Hi Denis,
> >
> > I think there=E2=80= =99s still a problem with the terminology in use here. What
> > you describe as RS2, which might in fact be an RS unto itself, is a
> > =E2=80=9CClient=E2=80= =9D in OAuth parlance because it is /a client of RS1/. What you
> > call a =E2=80=9Cclien= t=E2=80=9D has no analogue in the OAuth world, but it is not at
> > all the same as an OAuth client. I appreciate your mapping of the
> > entities below, but it makes it difficult to hold a discussion if we
> > aren=E2=80=99t using = the same terms.
> >
> > The good news is that this isn=E2=80=99t OAuth, = and as a new WG we can define
> > our own terms. The bad news is that this is really hard to do.
> >
> > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new definitions,
> > but we=E2=80=99ve got= a chance to be more precise with how we define things.
>
> In the ISO context, each document must define its own terminology. The
> boiler plate for RFCs does not mandate a terminology or definitions section
> but does not prevent it either. The vocabulary is limited and as long as
> we clearly define what our terms are meaning, we can re-use a term already
> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.=C2=A0 We ar= e clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.=C2=A0 If I understan= d correctly, a similar reasoning prompted Dick to
use the term "GS" in = XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.= ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org<mailto:Txauth@ietf.org>
https://www.= ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.= ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.= ietf.org/mailman/listinfo/txauth


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


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


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


--




--
--00000000000046193205acd96706-- From nobody Fri Aug 14 10:40:36 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 A19913A100E for ; Fri, 14 Aug 2020 10:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Mw25GQY5DfIi for ; Fri, 14 Aug 2020 10:40:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448DD3A0F85 for ; Fri, 14 Aug 2020 10:40:33 -0700 (PDT) Received: from [192.168.1.18] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07EHeTBn016146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Aug 2020 13:40:30 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_55831629-9CD5-4047-ACFC-B95CFA31D7FF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 14 Aug 2020 13:40:29 -0400 In-Reply-To: Cc: GNAP Mailing List To: Fabien Imbault References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Implementation of RS hiding 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: Fri, 14 Aug 2020 17:40:35 -0000 --Apple-Mail=_55831629-9CD5-4047-ACFC-B95CFA31D7FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fabien, Thank you for writing this up! This is really interesting to read = through, and it=E2=80=99s especially interesting to see that it = doesn=E2=80=99t seem to be that much of a lift on top of the base = protocol.=20 Now that you=E2=80=99ve built it, do you think there=E2=80=99s much of = an impediment for a developer to send the additional header alongside = the token? I think we need to explore some other ways this could run, = like using a structured header[1] for token presentation in this case. =E2=80=94 Justin [1] https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-17 = > On Aug 14, 2020, at 12:33 PM, Fabien Imbault = wrote: >=20 > Hello,=20 >=20 > Following discussions we had on the mailing list, here's a mvp which = includes RS hiding.=20 > https://github.com/acertio/mvp_gnap_privacy = >=20 > =3D> it works fine. >=20 > In the same release we also improved the IS flow (including Justin's = feedback), and started to implement a more realistic use case.=20 > The documentation has been updated accordingly.=20 >=20 > Fabien > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_55831629-9CD5-4047-ACFC-B95CFA31D7FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Fabien,

Thank you for writing this up! This is really interesting to = read through, and it=E2=80=99s especially interesting to see that it = doesn=E2=80=99t seem to be that much of a lift on top of the base = protocol. 

Now that you=E2=80=99ve built it, do you think there=E2=80=99s = much of an impediment for a developer to send the additional header = alongside the token? I think we need to explore some other ways this = could run, like using a structured header[1] for token presentation in = this case.

 =E2=80=94 = Justin


On Aug 14, 2020, at 12:33 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello, 

Following discussions we had on the = mailing list, here's a mvp which includes RS hiding. 
https://github.com/acertio/mvp_gnap_privacy

=3D> it works fine.

In the same release we also improved = the IS flow (including Justin's feedback), and started to implement = a more realistic use case. 
The = documentation has been updated accordingly. 
Fabien
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_55831629-9CD5-4047-ACFC-B95CFA31D7FF-- From nobody Fri Aug 14 11:08:14 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 0FB023A11AD for ; Fri, 14 Aug 2020 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 sewdGeqNbx6v for ; Fri, 14 Aug 2020 11:08:07 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 C8A713A0EB0 for ; Fri, 14 Aug 2020 11:08:07 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id z18so8263504otk.6 for ; Fri, 14 Aug 2020 11:08:07 -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=C0B2aP/mWQYjrIVbOOd/k8+FkhLnKiBxANBkOvPVF0g=; b=WQcju31UvUWWMGtPjr3gKo8RPxSLaBKhdb+hV9WBeXsq4M/Ng0zPTeq+J6ca0ny55a d8RN8zUplq84aue+JKyKav01m2nfxp0k5dK0m8UiFBU0Rk2nEa8xun3hkRcbhO4jf+A2 rUYbzjKyVzX3AvmwKxyTTTNv3E+lZTWc5lv+vNWRDTxlkznj55W0xpHdCx/FbJH8K5JW Qw97aZePAwyYP7jDshKy96DqBhjtP5oGPmq+0WaUtjjk3D4qamyhz66YPELNmLJectUJ 4VRxsf1ToVBCLu9I6xKXBJxc/AE5ajE2TXqK1MMFkJQbwmcXjyzHLBqQg1T1gLAOSXUE K/ig== 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=C0B2aP/mWQYjrIVbOOd/k8+FkhLnKiBxANBkOvPVF0g=; b=PUdaXw4BKdTAGI86LEw1P5sCW0PsO1T2oeWplXLR5bIZ8mFuArRPI+R6rhtnQ6fQrY cH7RvzeJIdAR6lo+RNZUALSktvoH3qL3l39tWxrtWQFiB9L15MhdTPrgGOWJ1xcz32pi rHZjV/Cv/cPqIuf+av9dSzapuFe815muc0L85Wi7rithXs3ZbeU4Y7fsRNHTXLn4aF0t AsHnIqgfVuLlYiq5PN3m7Z/URvYNaXnibO3iUv44uGyj9agZgZTYnAY6uu4sL5Or4d68 QLSxSYilQMKBPgn+5SCY3CWhjLFCeURVgu9YR8FuyN+xCv3Q/+zhp5yyXr6tfNAaZ5LV inJA== X-Gm-Message-State: AOAM530iUwkz0NEmqFcB7JEU+WT7DXdycgyaSoP0zl+8TrDTczPQ0P1F i5x28uAXzTgxnfyAc4ynM1GT+m8ANpKEUl0y3Ko= X-Google-Smtp-Source: ABdhPJwG9fi7B3pjXcuJyKCmUiq56QMlC6quNVti1qDE63QglCLniZR+pjcWu4PrYY1acrylx6XnzDzIK+CszN05y+U= X-Received: by 2002:a9d:84c:: with SMTP id 70mr2660031oty.358.1597428486928; Fri, 14 Aug 2020 11:08:06 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> In-Reply-To: <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> From: Tom Jones Date: Fri, 14 Aug 2020 11:07:55 -0700 Message-ID: To: Justin Richer Cc: Fabien Imbault , Denis , Dave Tonge , Francis Pouatcha , Mike Jones , Benjamin Kaduk , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000847a3f05acda4da4" Archived-At: Subject: Re: [GNAP] Terminology 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: Fri, 14 Aug 2020 18:08:12 -0000 --000000000000847a3f05acda4da4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable that works for me The roles that an end user agent might expose are Subscriber Applicant Authenticated user Authorized user Resource owner Delegate Principal Administrator Legal override Emergency (public Health) override The last three roles are not (necessarily) a single human being, but can only be represented by a single human in a role. See my submission on Delegation for a binding between a human and a role. I would avoid payments - that is a can of worms that has no common internationally (meaning more that 6 countries) accepted approach. And the only convergence seems to be the Google dominated one. Peace ..tom On Fri, Aug 14, 2020 at 7:30 AM Justin Richer wrote: > +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps =E2=80= =9C operator=E2=80=9D as > the role they play when, you know, operating the . (Where > should still have a more specific name.) > > =E2=80=94 Justin > > On Aug 14, 2020, at 8:23 AM, Fabien Imbault > wrote: > > Hi Denis, > > Thanks for your feedback. > Comments inline (marked with FI). > > Fabien > > On Fri, Aug 14, 2020 at 12:02 PM Denis wrote: > >> Hi Fabien, >> >> Thank you for your inputs, a ball is finally rolling. >> >> An attempt. >> >> I would add upfront: User =3D human person >> >> FI : then end-user is clearer if you want to indicate specifically a > human user. One can also create system users. > >> * =3D application that requests access to Resource Servers (RS) >> through a Grant Server (GS). * >> Examples: a web server, a browser-based app, a mobile app, an IoT device= . >> >> A few explanations: "through" does not sound appropriate since it could >> be interpreted as the GS being necessarilly placed between the Client an= d >> the RS. >> In addition, more than one GS may >> be necessary. >> >> My proposal: * =3D application that requests access to Resource >> Servers (RS) **on behalf of a User by using one or more Grant Servers >> (GS) * >> *Examples: a web server, a browser-based app, a mobile app.* >> >> FI: agreed. > >> >> *GS =3D computing service that manages the grant lifecycle to a = on >> behalf of a Resource Controler (RC).* >> Note : for privacy reasons, the GS may be issuing grants without >> knowledge of which resources are requested. >> >> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be >> fully ignorant of the existence of the RSs and hence of the RCs. >> In addition, "*grant life cycle*" is undefined. >> >> My proposal: *GS =3D server issuing access tokens to a Client after >> successfully authenticating the User* >> >> >> *Note 1: for privacy reasons, the GS may be issuing access tokens withou= t >> the knowledge of which resources are requested.Note 2: a GS is able to >> disclose to a User the User attributes that it manages. * >> >> FI: I find the new definition less clear. It's not because you don't kno= w > which RS is called that we shouldn't say the decision is made by the RC. > "grant life cycle" is indeed currently undefined, what i had in mind is > basically the grant flow from the GNAP protocol, possibly also including > revocation etc. > Not sure why Note 2 is important to put here. > > >> *RS =3D computing service that grants access only if its Resource Contro= ler >> (RC) consents.* >> Note : the consent may involve a human interaction or may be automated >> based on access control policies. >> >> I dislike "*its Resource Controler (RC) consents" *because it may let >> think that a human person always needs to consent. >> >> My proposal: *R* >> *S =3D server hosting protected resources, capable of accepting and >> responding to protected resource requests >> when access tokens are being used* >> >> FI : that is why I suggested a note to make sure it is correctly > understood. I'm not sure the proposed alternative is clearer. > >> >> *RC =3D entity which is controlling the access to a protected resource. = * >> Note : a RC may be manually operated by a human or delegated to a >> machine, partially or completely. >> >> A RC is not an entity but a function. I would also place the machine cas= e >> first. >> >> My proposal: >> *RC =3D function tightly coupled with a RS which controls the accesses t= o a >> protected resource* Note : the function may be >> operated either by a machine or by a human person or by some combination= of >> both. >> >> FI : your proposition on the note makes it much better. On the main > definition, I'm not sure what you mean by function, as a result I'm not > sure a reader would understand. Why do you need to say "tightly coupled?" > >> *Consent =3D the process of asking a RC to accept or decline based on a >> grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D = or =E2=80=9Cno=E2=80=9D consent >> decision.* >> >> I would instead speak of the "User Consent". The User Consent is a set o= f >> choices among a proposed set of choices. It is not simply a "yes" or "no= " >> consent decision. >> >> My proposal: *User Consent =3D ability for a User, after being informed, >> of choosing to release or not to a RS some attributes contained in one o= r >> more access tokens* >> >> > FI: this may be misleading I think. The consent is done by a RC (or in > OAuth terms, RO), not the application user. > I agree there may be a combination of consent decisions, but I think it's > important to say that in the end for each individual choice, you do have = a > yes/no decision. > >> >> Denis >> >> >> Fabien >> >> On Thu, Aug 13, 2020 at 3:55 PM Denis wrote: >> >>> Fabien, >>> >>> IMHO, nothing is wrong with keeping "Client" since it has a wide spread >>> usage >>> ... but only as long as we can agree on a short and a clear definition >>> for it. >>> >>> I can provide the beginning of such a definition: " application ..." >>> >>> If someone could go a little bit further, this would help. :-) >>> >>> A similar argumentation for GS. It could be used but only as long as >>> we can agree on a short and a clear definition for it. >>> Any proposal ? >>> >>> Denis >>> >>> Hi, >>> >>> Nothing inherently wrong with Client/AS, which has worked for years in >>> the context of OAuth2. The question is to know whether we can build the= new >>> protocol with the same concepts and deal with their known limitations, = or >>> if we're better off with more adapted concepts less prone to >>> misunderstandings. >>> >>> Verb vs Noun: >>> Problem is that the grant (noun) can only be understood if there is a >>> grant(verb), i.e. some action that grants something. >>> The grant (noun) definition directly derives from the verb : "something >>> granted ..." >>> >>> I personally have no issue even with the fairly convoluted "The Grant >>> Server issues a grant to the Grant Client representing access that has = been >>> granted" (except perhaps from the word Client, but that's a different >>> issue). >>> By the way, grant is nothing new, it's used extensively in OAuth2 as >>> "grant types" (whatever that means). >>> >>> Dick summarized well the reasons why he uses GS instead of AS : >>> 1) "grant" is in the working group name (a weaker reason, but still has >>> been approved). Question: would our reasoning if the protocol ended up >>> being called OAuth3? >>> 2) grant =3D larger in scope than AS (not only authorization), as it at >>> least includes idclaims + other use cases like payment (?) - no consens= us, >>> see difference in appreciation between Justin and Dick >>> >>> As for "Client", if most people think it is problematic, it seems a goo= d >>> reason to change if we find a better alternative. >>> Quoting Dick again: "The confusion in my experience usually stems from >>> people working with software that is acting in multiple roles. IE, the >>> software that is acting as a client in once context, is also acting as >>> an RS in other contexts, or even acting as an AS. The other confusion i= s >>> that people view clients as being the software the user is using -- >>> although it may not be acting as a client in the oauth context." and >>> later "I do agree that it is not the best term in GNAP. Primarily becau= se >>> GNAP is a combination of the client from OAuth 2, and the relying party >>> from OIDC." >>> >>> So far there's no consensus however, recent tries: Initiating >>> Application (Denis), Orchestrator (Francis). >>> >>> Cheers >>> Fabien >>> >>> >>> >>> >>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >>> wrote: >>> >>>> I would be against using "grant" as both a verb and a noun and stick >>>> purely with one or the other. (In the charter the only use of "grant" = is in >>>> the verb: "granted"). >>>> >>>> Using it as both a verb and a noun will be confusing and less >>>> accessible. >>>> >>>> I think it will be confusing to say "The Grant Server issues a grant t= o >>>> the Grant Client representing access that has been granted" >>>> >>>> Whether the access takes place via a token being returned and used at = a >>>> resource server, or "claims" that are directly returned from the "Gran= t >>>> Server" I think should be largely irrelevant when it comes to the nami= ng of >>>> the roles. >>>> >>>> In almost all use cases that I have seen the "Grant Server" is making = a >>>> policy based decision "to grant" access to requested resource(s). To m= e, >>>> that is the fundamental operation happening. I think nearly all use ca= ses >>>> can be applied to that, e.g. the GS grants access to >>>> - identity attributes for the end user >>>> - verify an identity attribute (e.g. that user is over 18) >>>> - all users photos at resource server X >>>> - a single photo with id 12345 at resource server Y >>>> - resource of type X at any resource server that trusts the Grant >>>> Server >>>> - call a payment API with specific properties (e.g. amount < 5) >>>> - call a file storage API >>>> - call a "contract signing" API with specific properties (e.g. >>>> contract hash of xxx,) >>>> >>>> While "client" is problematic, it does now have wide spread usage, so >>>> perhaps we are stuck with it. >>>> However I agree with Justin and think "Grant Client" makes things more >>>> confusing. >>>> >>>> What is wrong with keeping "Client" and "Authorization Server"? >>>> >>>> Dave >>>> >>>> >>>> >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000847a3f05acda4da4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
that works for me
The roles that an end user agent mig= ht expose are
Subscriber
Applicant
Authenticated use= r
Authorized user
Resource=C2=A0owner
Delegat= e
Principal
Administrator
Legal override
Emergency=C2=A0(public Health) override
The last three role= s are not (necessarily) a single human being, but can only be represented b= y a single human in a role.=C2=A0 See my submission on Delegation for a bin= ding between a human and a role.

I would avoid pay= ments - that is a can of worms that has no common internationally (meaning = more that 6 countries) accepted approach. And the only convergence seems to= be the Google dominated one.
Peace ..tom


On Fri, Aug 14, 2020 at 7:3= 0 AM Justin Richer <jricher@mit.edu> wrote:
+1 for =E2=80=9Cend user=E2=80=9D a= s the human person, and perhaps =E2=80=9C<client> operator=E2=80=9D a= s the role they play when, you know, operating the <client>. (Where &= lt;client> should still have a more specific name.)

= =C2=A0=E2=80=94 Justin


=
Hi Denis,=C2=A0

Thanks for your feedback.=C2=A0
Comments inline (marked = with FI).

Fabien

On Fri, Aug 14, 2020 at 12:02 PM D= enis <denis.ietf= @free.fr> wrote:
Hi Fabien,

Thank you for your in= puts, a ball is finally rolling.

An attempt.
I= would add upfront: User =3D=C2=A0 human person
FI : then end-user is clearer if you want to indicate specifically= a human user. One can also create system users.
<Client> =3D application that requests access to Resou= rce Servers (RS) through a Grant Server (GS).=C2=A0=C2=A0
Exa= mples: a=C2=A0web server, a browser-based app, a mobile app, an IoT device.=

A few explanations: "thr= ough" does not sound appropriate since it could be interpreted as the = GS being necessarilly placed between the Client and the RS.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition, more than one GS= may be necessary.

My proposal:=C2=A0= =C2=A0<Client> =3D application that requests access to Reso= urce Servers (RS)=C2=A0on behalf of a=C2=A0User=C2=A0by using one or more Grant Servers (GS)=C2=A0
Examples: a=C2=A0web server, a browser-based app, a mobile app.=

FI: agreed.=C2=A0=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=
GS =3D computing service that manages the grant lif= ecycle=C2=A0to a <Client> on behalf of a Resource Controler (RC).=
Note : for privacy reasons, the GS may be issuing grants without= knowledge of which resources are requested.
=

I dislike "on behalf of a Resource Controler (RC)". The GS may be fully ignorant of the existence of the RSs and hence= of the RCs.
In addition, "grant life cycle" is undefin= ed.

My proposal:=C2=A0=C2=A0GS =3D=C2=A0server issuing access tokens to a Client after successful= ly authenticating the User
Note 1: for privacy reasons, the GS ma= y be issuing access tokens without the knowledge of which resources are req= uested.
Note 2: a GS is able to disclose to a User the User attributes t= hat it manages.=C2=A0=C2=A0

FI: I find the new definition less clear. It's not becaus= e you don't know which RS is called that we shouldn't say the decis= ion is made by the RC.=C2=A0
"grant life cycle" is inde= ed currently undefined, what i had in mind is basically the grant flow from= the GNAP protocol, possibly also including revocation etc.
Not s= ure why Note 2 is important to put here.
=C2=A0

RS =3D compu= ting service that grants access only if its Resource Controler (RC) consent= s.
Note : the consent may involve a human interaction or may = be automated based on access control policies.
I dislike "its Resource Controler (RC) consents"= =C2=A0because it may let think that a human person always = needs to consent.

My proposal:=C2=A0RS =3D se= rver hosting protected resources, capable of accepting and responding to pr= otected resource requests=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 when access tokens are being used
FI : that is why I suggested a note to make sure it is= correctly understood. I'm not sure the proposed alternative is clearer= .=C2=A0

= RC =3D entity which is controlling the access to a protected resource.= =C2=A0
Note : a RC may be manually operated by a human or del= egated to a machine, partially or completely.

A RC is not an entity but a function. I would also place th= e machine case first.

My proposal:=C2=A0RC =3D functi= on tightly coupled with a RS which controls the accesses to a protected res= ource
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Note : the function may be operated either by a machine or by a human p= erson or by some combination of both.

FI : your proposition on the note makes it much better. On the main defi= nition, I'm not sure what you mean by function, as a result I'm not= sure a reader would understand. Why do you need to say "tightly coupl= ed?"=C2=A0
<= div>Consent =3D the process of asking a RC to accept or decline based on= a grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D = or =E2=80=9Cno=E2=80=9D consent decision.

I would instead speak of the "User Consent". The = User Consent is a set of choices among a proposed set of choices. It is not= simply a "yes" or "no" consent decision.

My = proposal:=C2=A0User Consent =3D ability for a User, after b= eing informed, of choosing to release or not to a RS some attributes contai= ned in one or more access tokens


FI: this may be misleading I think. The consent is done by= a RC (or in OAuth terms, RO), not the application user.=C2=A0
I = agree there may be a combination of consent decisions, but I think it's= important to say that in the end for each individual choice, you do have a= yes/no decision.=C2=A0


Denis


Fabien

On Thu, Aug 13, 2020= at 3:55 PM Denis <denis.ietf@free.fr> wrote:
Fabien,

IMHO= , nothing is wrong with keeping "Client" since it has a wide spre= ad usage
... but only as long as we can agree on a short and a clear def= inition for it.

I can provide the beginning of such a definition: &qu= ot; application ..."

=
If someone could go a little bit further, t= his would help. :-)

=
A similar argumentation for GS.=C2=A0 It could be= used but=C2=A0only as long as we can agree on a short and a clear definition for it.
Any proposa= l ?

Denis

=
Hi,

Nothing inherently wrong with Client/AS, which has wor= ked for years in the context of OAuth2. The question is to know whether we = can build the new protocol with the same concepts and deal with their known= limitations, or if we're better off with more adapted concepts less pr= one to misunderstandings.

Verb vs Nou= n:
Problem is that the grant (noun) can only be understood if there is= a grant(verb), i.e. some action that grants something.=C2=A0
The grant= (noun) definition directly derives from the verb : "something granted= ..."

I personally=C2=A0have no issue even with= the fairly convoluted "The Grant Server issues a grant to the G= rant Client representing access that has been granted" (except perhaps= from the word Client, but that's a different issue).
= By the way, grant is nothing new, it's used extensively in OAuth2= as "grant types" (whatever that means).=C2=A0
<= span>
Dick sum= marized well the reasons why he uses GS instead of AS :=C2=A0
<= div>1) "grant" is in the = working group name (a weaker reason, but still has been approved). Question= : would our reasoning if the protocol ended up being called OAuth3?<= /div>
2) grant =3D larger in sc= ope than AS (not only authorization), as it at least includes idclaims=C2= =A0+ other use cases like payment (?) - no consensus, see difference in app= reciation between Justin and Dick

As for "Client", if most people think it is problematic, it se= ems a good reason to change if we find a better alternative.=C2=A0
Quoting Dick again: "= The confusion in my experience usually stems from people working=C2= =A0with software=C2=A0that is acting in multiple=C2=A0roles. IE, the softwa= re=C2=A0that is acting as a=C2=A0client=C2=A0in once context, = is also acting as an RS in other contexts, or even acting as an AS. The oth= er confusion is that people view=C2=A0clients=C2=A0as being th= e software the user is using -- although it may not be acting as a=C2=A0client=C2=A0in the oauth context." and later "I do agre= e that it is not the best term in GNAP. Primarily because GNAP is a combina= tion of the=C2=A0client=C2=A0from OAuth 2, and the relying par= ty from OIDC."

<= /font>
So far there's= no consensus however, recent tries: Initiating Application (Denis), Orches= trator (Francis).=C2=A0

Cheers
Fabien
<= br>



<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 13, 2020 at 2:59 PM Dave T= onge <dave.= tonge@moneyhub.com> wrote:
I would = be against using "grant" as both a verb and a noun and stick pure= ly with one or the other. (In the charter the only use of "grant"= is in the verb: "granted").

Using i= t as both a verb and a noun will be confusing and less accessible.

I think it will be confusing to say "The = Grant Server issues a grant to the Grant Client representing access that ha= s been granted"

Whether the access takes plac= e via a token being returned and used at a resource server, or "claims= " that are directly returned from the "Grant Server" I think= should be largely irrelevant when it comes to the naming of the roles.

In almost all use cases that I have seen the "Gr= ant Server" is making a policy based decision "to grant" acc= ess to requested resource(s). To me, that is the fundamental operation happ= ening. I think nearly all use cases can be applied to that, e.g. the GS gra= nts access to
=C2=A0- identity=C2=A0attributes for the end user
=C2=A0- verify=C2=A0an identity attribute (e.g. that user is over = 18)
=C2=A0- all users photos at resource server X
=C2= =A0- a single photo with id 12345 at resource server Y
=C2=A0- re= source of type X at any resource server that trusts the Grant Server
<= div>=C2=A0- call a payment API with specific properties (e.g. amount < 5= )
=C2=A0- call a file storage API
=C2=A0- call a "= contract signing" API with specific properties (e.g. contract hash of = xxx,)
=C2=A0
While "client" is problematic, i= t does now have wide spread usage, so perhaps we are stuck with it.=C2=A0
However I agree with Justin and think "Grant Client"= makes things more confusing.

What is wrong with k= eeping "Client" and "Authorization Server"?=C2=A0
=

Dave



=

Moneyhub Enterprise is a trading style of = Moneyhub Financial Technology Limited which is authorised and regulated by = the Financial Conduct Authority ("FCA"). Moneyhub Financial Techn= ology is entered on the Financial Services Register (FRN 809360) at= =C2=A0https://register.fca.org.uk/. Moneyhub Financial Technology i= s registered in England & Wales, company registration number 06909772. = Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regu= s Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

DISCLAIMER: This email (= including any attachments) is subject to copyright, and the information in = it is confidential. Use of this email or of any information in it other tha= n by the addressee is unauthorised and unlawful. Whilst reasonable efforts = are made to ensure that any attachments are virus-free, it is the recipient= 's sole responsibility to scan all attachments for viruses. All calls a= nd emails to and from this company may be monitored and recorded for legiti= mate purposes relating to this company's business. Any opinions express= ed in this email (or in any attachments) are those of the author and do not= necessarily represent the opinions of Moneyhub Financial Technology Limite= d or of any other group company.




--=C2=A0
TXAuth mailing list
TXAuth@ietf.org
https= ://www.ietf.org/mailman/listinfo/txauth
<= /blockquote>

--000000000000847a3f05acda4da4-- From nobody Fri Aug 14 12:43:16 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 8F19E3A03FB for ; Fri, 14 Aug 2020 12:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 xUdydIFK8VzJ for ; Fri, 14 Aug 2020 12:43:13 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 BC3A83A03F6 for ; Fri, 14 Aug 2020 12:43:13 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id a5so11796140ioa.13 for ; Fri, 14 Aug 2020 12:43:13 -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=UrFbTdUYsow03Iz/yhPChzp1fG49bJLpa3w5HA+QKuw=; b=ia3ZF92bTugpeg+3vKxEQWZ1xIhnf+gewhcRcZVGmtB4RglczBIAW3I3NX+TIoTiQu KQGhSR2czMtDfu86r30RdjkNZkdTGRDXtl5yRyGVqV3fs5mf5hDRizK6LpGhEpneBNx3 JJbxua4XLu+CpeDCJmWzNv3kyJ+/5gxlo/aVaFCcp7DE5tH0hn+vCUYCoVwiiNBsxgVx ONnLx5e1ggvDptXHOlj4RxDLUHkSkMRX1y3J0euECWCNOnv7bgsfG3P5eUYMUxCZ6xVj YDdWEMaZwmVtt+KbHRVXC8l81gMExDK0U7vOqDNAe5CBpJVH3TmSlYh3G6AQcwZ6cqXZ E59g== 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=UrFbTdUYsow03Iz/yhPChzp1fG49bJLpa3w5HA+QKuw=; b=rn0i3A4OrD9PdDKvWMxGCoXYtDXMiYEqftLRMLm4mZtzivXNEY0E53+6d/8x0qE/FF 1jBcq4tUZB9VgtoBScyAxTwm3Yv6oSoo7vIDs67isddKXTmIdQD1XkejY5yDzOIT9J0I dxwxr5v7OVUejriXM/zYm6WR0nGoUXridZXjm/cJZ20qSdC2/D1BtNsm/e/KMdsh7pFM x6nugcfg85yV3q1XlQYqpviYAB6xze4tRSvSWMyeHs3YTo6hKug8PrxvaIZyKxVJNKdr DGdX9mcVs9fxDFNd+2bUACQOvc4I0R+SEjxMgXixL/it2YhxZLpVeG4fWlYLKAK8qges EIrw== X-Gm-Message-State: AOAM532aNhtjYCDerCRX5x/0gC15FSmZj8bya8qYmRnZc2mAR0taA7NY 4ejqp0+0saPncsALAlc1sSTq9U+l7Y/vmC17LB8= X-Google-Smtp-Source: ABdhPJx1hTs/GjzGr4tOPbnu35/sKHInTK0Y1twKnA9i7S6Lzoiio2EZwUNakKv1iv2yx8ArisSq56nnmUeJ6hoaolg= X-Received: by 2002:a05:6602:2fcf:: with SMTP id v15mr3329301iow.78.1597434192970; Fri, 14 Aug 2020 12:43:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Fri, 14 Aug 2020 21:43:02 +0200 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000009fcc2b05acdba1f0" Archived-At: Subject: Re: [GNAP] Implementation of RS hiding 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: Fri, 14 Aug 2020 19:43:16 -0000 --0000000000009fcc2b05acdba1f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, At least for now I think it does the job very well. Haven't used structured headers so far but did read some interesting articles from fastly. https://www.fastly.com/blog/improve-http-structured-headers Cheers Fabien Le ven. 14 ao=C3=BBt 2020 =C3=A0 19:40, Justin Richer a = =C3=A9crit : > Fabien, > > Thank you for writing this up! This is really interesting to read through= , > and it=E2=80=99s especially interesting to see that it doesn=E2=80=99t se= em to be that much > of a lift on top of the base protocol. > > Now that you=E2=80=99ve built it, do you think there=E2=80=99s much of an= impediment for a > developer to send the additional header alongside the token? I think we > need to explore some other ways this could run, like using a structured > header[1] for token presentation in this case. > > =E2=80=94 Justin > > [1] https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-17 > > On Aug 14, 2020, at 12:33 PM, Fabien Imbault > wrote: > > Hello, > > Following discussions we had on the mailing list, here's a mvp which > includes RS hiding. > https://github.com/acertio/mvp_gnap_privacy > > =3D> it works fine. > > In the same release we also improved the IS flow (including Justin's > feedback), and started to implement a more realistic use case. > The documentation has been updated accordingly. > > Fabien > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000009fcc2b05acdba1f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

A= t least for now I think it does the job very well.=C2=A0

Haven't used structured headers so far= but did read some interesting articles from fastly.=C2=A0

Cheers
Fabien


Le ven. 14 ao=C3= =BBt 2020 =C3=A0 19:40, Justin Richer <jri= cher@mit.edu> a =C3=A9crit=C2=A0:
Fabi= en,

Thank you for writing this up! This is really intere= sting to read through, and it=E2=80=99s especially interesting to see that = it doesn=E2=80=99t seem to be that much of a lift on top of the base protoc= ol.=C2=A0

Now that you=E2=80=99ve built it, do you= think there=E2=80=99s much of an impediment for a developer to send the ad= ditional header alongside the token? I think we need to explore some other = ways this could run, like using a structured header[1] for token presentati= on in this case.

=C2=A0=E2=80=94 Justin

On= Aug 14, 2020, at 12:33 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello,=C2=A0

Following discussions we = had on the mailing list, here's a mvp which includes RS hiding.=C2=A0

= =3D> it works fine.

In the same release we also= improved the IS flow (including Justin's feedback),=C2=A0and started t= o implement a more realistic=C2=A0use case.=C2=A0
The documentati= on has been updated accordingly.=C2=A0

Fabien
--
TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--0000000000009fcc2b05acdba1f0-- From nobody Sat Aug 15 16:03:24 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 C9B403A0406 for ; Sat, 15 Aug 2020 16:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 66u9lJadAv1o for ; Sat, 15 Aug 2020 16:03:18 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 E290C3A03FB for ; Sat, 15 Aug 2020 16:03:17 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id v4so13631929ljd.0 for ; Sat, 15 Aug 2020 16:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kfcyF+dqWHlgvXGFfBMDkPUK51HDL9lqB3xO92hzNlA=; b=Q8oFQVnLErnt/Pda7dT/VyOvHY6j0t9xzXf+1Fu+a8v/KWBH2eK7spkzPea3rjNv6c mGPeU4Sxa1PDBbjfwCrN8iQ5oDX0M2Tx/J1rWuQMZgvLMkgmVAvPZNi+NJ8DDHfQy/K7 3Lhv/OigAtuFi4a8hVGVogo7FFUPHsYyTqgGRCGv0FPhn12QToEj7AMgkIwIz31W3b3z IdX7idOtEA2E5wYc7T7rExO83UNZ6G0L8hXpQ2/BXgttfKFCSBINUjZinKPa5isWxKYT cwHhetEmaW8fYAjqFF6/zqM+B7jJdUali9aZUSmxBURdRjifGKSMX+NEWPeK2qDLONcS hRZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kfcyF+dqWHlgvXGFfBMDkPUK51HDL9lqB3xO92hzNlA=; b=XAxBN57VLeyTFfGBp+9pS740IT8twnNYFIerJDVNK8FCjsfFkZq9Xj0wofCnTB+DoC KOUC9GoXTicwzp0J8Yjwhej2v87E2AuU2yVxpmRu9tfzRhv/rQWZQZcg6ZSOlLd7fAZj R4h9i7ZQC9ILqk0YmvaejJDsbNXuEYlfede69T5+slHltpYfjNRjcHy5AQwvW7SlTGF4 ax373gYEz15thHnAasCpe/UK34ctXi4bqgtjVRBkS/IwyJZgr0RY6CUfOAreeKV3Xy9e ZtofJfTpNQqfDkE1knEr4QOh1gI/+AVuHqvXxxCFfgz5MdXvGQP+/maRcEMCEyUWGMyt l58g== X-Gm-Message-State: AOAM532Zf5FzO4MFVTrI9TAleXcas/0NTJT4Yd0g1g4j6aApEyMAh/HB K4/ezo5ZdXVsX2k1Tx855ptvgIqJFb5zarjzu5PUypHhrpModw== X-Google-Smtp-Source: ABdhPJz2fCXKz3d75XVdISopG67U1LUuzMCzVFcE0KPgVXoaOoMb185uPjGTqpVogJ3QOM3/UzRFX7KcCSAsAF6wFAI= X-Received: by 2002:a2e:b0db:: with SMTP id g27mr4538871ljl.69.1597532595191; Sat, 15 Aug 2020 16:03:15 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Sat, 15 Aug 2020 16:02:39 -0700 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000da831005acf28af3" Archived-At: Subject: [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: Sat, 15 Aug 2020 23:03:22 -0000 --000000000000da831005acf28af3 Content-Type: text/plain; charset="UTF-8" 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. --000000000000da831005acf28af3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000a8e4a805ad04a6fc-- From nobody Sun Aug 16 15:46:54 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 13F6B3A1221 for ; Sun, 16 Aug 2020 15:46:53 -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 UfKJoQs12TP3 for ; Sun, 16 Aug 2020 15:46:49 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 554F53A1222 for ; Sun, 16 Aug 2020 15:46:47 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id x5so11823317wmi.2 for ; Sun, 16 Aug 2020 15:46:47 -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=YnomPVeRAlUcVzJ0bEhRFOuLd0VVTdOvximu/wl5nKo=; b=Q3BdosgesMPqAUg6WKL1cc2A2yltyGCR33AtiY6GwAwclMomDq43lYmPxbft7BBQae txlMdf7RIFuL35SoiSMzMbySZj242y903tP8ZTU0A7UYfIAmgYQlrBCN1g2kbZhDenIN ZZgTEcqYHi/012+U/+TjEJT0FwNpNSdYLwmcU= 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=YnomPVeRAlUcVzJ0bEhRFOuLd0VVTdOvximu/wl5nKo=; b=l4jqyFw2ySBTTVwzz9IflCk/LeXp5CdjHZ00KTST7Rr+Gy6jBAQbWhKdH9hMissBGX N8B/2aTnwzRNVudCWuupHErfMor+ESiu+Plyet9VfxONuyiG1g9CYJfwdVd0CSeSpQab FZvnqklJps2Lm4DBlH8+Dr4mqHxnxVc3t2u33zvxLXsAnGQtr/FO/MfXF54qr85cO6sf xRC4DOlbstPaQxQtPk4quUBC/+dEX+sNb7NuYDVOXQov2eK8rZv2KLVrWBC3lJMvCfCI i+g6CtDLCRgfZgfMATbDcJx8NtCrdfyiQqm+R+De7zcpg6O7VxmS3A4WQrTz0O6Pz3y0 UdNQ== X-Gm-Message-State: AOAM533ddycxLRaRNLfweSNjvmPq9f8Y0c+k4DZaCsf+LXbmCWvlbhtJ gvAThWceD+iZyrKJRS6JPm55jPSYnowpgDmpBHZvcg== X-Google-Smtp-Source: ABdhPJyNb20ppTnWus3NrsDZQ0J+apS+EJwq8TZcYntHEq+jNaeyn8fG2vRAes7fqvoBxXDNVKp6MHFh6aLGkh+5x8U= X-Received: by 2002:a1c:770c:: with SMTP id t12mr12947700wmi.65.1597618006098; Sun, 16 Aug 2020 15:46:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Sun, 16 Aug 2020 18:46:35 -0400 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000bd988b05ad066d11" 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: Sun, 16 Aug 2020 22:46:53 -0000 --000000000000bd988b05ad066d11 Content-Type: text/plain; charset="UTF-8" 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/ --000000000000bd988b05ad066d11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dick,=C2=A0my feedback below:

1.2: Excellent and Focussed
-> The word &qu= ot;Grant Client" looks great for me.

1.3:
Title: Human Inter= action -> 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 ei= ther human on an IOT device or a car or ...

Participant: User -> = "Requesting Party"
I will still insist on replacing the word &= quot;User" with a role name. Maybe "Requesting Party" as use= d by UMA.

Participant: "Resource Controller". In past disc= ussions there was a consensus on using "Resource Controller" inst= ead.

(B) I which the GS never interacts with the "Requesting Pa= rty" in a matter of obtaining a grant to a resource (many reasons: pri= vacy, confidentiality, abstraction, ...). Generally the GS will need inform= ation (claims) about the "Requesting Party" to proceed with the a= uthorisation decision. In this case, the GS can instruct the GC to obtain t= hose claims. In some cases, claims on the "Requesting Party" will= be obtained from another "Authorization Server" (AS). The word A= S 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 Part= y, and the Resource Controller).

The result can look like the modifi= ed diagram below. With this we can address some privacy concerns that are b= eing 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=A0Reso= urce =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|
=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|<= br>=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) repl= ace (B). Occur inside step (3), GS asks GC to collect the claims. GC contac= ts RP-AS to negotiate those=C2=A0claims. But it is important to mention tha= t those Claims-RP are not the target Grant being negotiated for the resourc= e access. They are generally=C2=A0used by GS (and later RS) as input into p= erforming authz decisions.

(C0, C1) replace (C). They occur= =C2=A0after step (3) (Beware of the difference=C2=A0to Bs that occur=C2=A0i= nside 3). This separation address the Big Brother problem we have been disc= ussing in the list.

Essential is to mention that in an instan= tiation 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 Us= er".=C2=A0

Off-topic: Th= e splitting of GS and AS was suggested in some discussions on the mailing l= ist. But we have no mean yet to isolate good inputs for later reuse. This i= s 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 neede= d to have a structure for this section.


1.5
I suggest again w= e replace Human with "End User" and still make them roles. This i= s:
Terminology (Are all roles)
=C2=A0 -> These roles can be borne = by End Users
=C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)
=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 fund= amental 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 = <dick.hardt@gmail.com> wr= ote:
<= div>Hello

I just pushed an updated version of XAut= h:


Highlights:<= /div>
  • renamed Client -> Grant Client
  • Introduced Client Ow= ner, 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 r= oles 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

Th= e use of GNAP in this document is not intended to be a declaration of it be= ing endorsed by the GNAP working group.

This document describes the core Grant Negotiation and Authoriza= tion Protocol (GNAP). The protocol supports the widely deployed use cases s= upported 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. Rel= ated documents include: GNAP - Advanced Features=C2=A0[GN= AP_Advanced]=C2=A0and JOSE Authentication=C2=A0[JOSE_Authentication]=C2=A0that describes the JOSE mecha= nisms for client authentication.

T= he technology landscape has changed since OAuth 2.0 was initially drafted. = More interactions happen on mobile devices than PCs. Modern browsers now di= rectly support asymetric cryptographic functions. Standards have emerged fo= r signing and encrypting tokens with rich payloads (JOSE) that are widely d= eployed.

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

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

The suggested pronunciation of GN= AP is "guh-nap".

1.1.=C2=A0The = Grant

The Grant is at the center of the pro= tocol 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 G= rant Server acquires authorization to grant the Grant to the Grant Client. = The Grant Server then returns the Grant to the Grant Client.<= /a>

The Grant Request may contain information ab= out the User, the Grant Client, the interaction modes supported by the Gran= t Client, the requested identity claims, and the requested resource access.= Extensions may define additional information to be included in the Grant R= equest.

1.2.=C2=A0P= rotocol 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 th= e RS requires from a GS for resource access. This step is not in scope for = this document.

(2) The GC make= s 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 m= echanism is=C2=A0[JOSE_Authentication].<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.2-4" style=3D"text-decoration-line:none;color:rgb(102,102,102)" targe= t=3D"_blank">

(3) The GC and GS may negotiat= e the Grant.

(4) The GS return= s a Grant to the GC (Grant Response=C2=A0Section 4.1).

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

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

1.3.=C2=A0H= uman Interactions

The Grant Client may be i= nteracting with a human end-user (User), and the Grant Client may need to g= et authorization to release the Grant from the User, or from the owner of t= he resources at the Resource Server, the Resource Owner (RO)<= /a>

Below is when the human interactions may occ= ur 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. 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 re= source 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 authori= zation

(4) The GS r= eturns 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

Alternativ= ely, the Resource Owner could be a legal entity that has a software compone= nt that the Grant Server interacts with for Grant authorization. This inter= action is not in scope of this document.

1.4= .=C2=A0Trust Model

In add= ition to the User and the Resource Owner, there are three other entities th= at are part of the trust model:

These three entities do not interact in the pr= otocol, 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 G= rant 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 resourc= es

1.5.=C2=A0Terminology

Roles

=

  • Grant Client=C2=A0(GC)

    • may want access to res= ources 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
      • <= /ul>

    • Grant Server= =C2=A0(GS)

    • = 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

    Humans

    • User

      • the person interacting with the Grant Client.=
      • has delegated access to identity claims abou= t 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 acce= ss management to the GS.

    Reused Terms

    • access token=C2=A0- an access 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 Claim as defined in=C2=A0[OIDC]=C2=A0Section 5. Cla= ims are issued by a Claims Issuer.
    • 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[RFC7519]=C2=A0Section 2.
    • auth= N=C2=A0- short for authentication.
    • authZ=C2=A0- short for authorization.

    New Terms

    • GS URI=C2=A0- the endpoint at the GS the GC ca= lls 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 ma= y 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 n= ot 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 H= andle=C2=A0- a unique identifier at the GS for a Dynamic Client fo= r 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 inte= raction modes: "redirect", "indirect", and "user_c= ode" in=C2=A0Section 5.
      • Grant=C2=A0- the user identity claims and/o= r 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.
    • Ac= cess=C2=A0- 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=C2=A0- the URI that = represents the Access the GC was granted by the RO. The Access URI MUST sta= rt 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/
--000000000000bd988b05ad066d11-- From nobody Sun Aug 16 16:04:45 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 D71E43A1237 for ; Sun, 16 Aug 2020 16:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 6PiI-5JuIZgT for ; Sun, 16 Aug 2020 16:04:39 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 8C6983A122F for ; Sun, 16 Aug 2020 16:04:38 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id b11so7422062lfe.10 for ; Sun, 16 Aug 2020 16:04:38 -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=0fyH5mQDUsURP1bl+/KKQb8XEWjHUh2li5zD+MUTlro=; b=GxvNLjWSZFP5poHUaHj7zyw94KTFdDM1gHTciHKWeso8g6amBYGA5pKDupypdPsr3k iRsTLGXdxZ0EXQGqXjlB8f44RxYJPu3Z5l3INnRW4SElGTIeBBjrqHhwcHxgj7PG8Ny4 kNul2V5KePuVIIh4p5vMgtjdkrMz83oWSGUkydvPEG5EtSzr7hnrtWPkERM2AhplCrRj EtyFXFMx2GQxwAsYQ7GPuB4ogeofMeXj4UkWRJ6maVfAY36qoUp0E7KDEQRQewyTPUm8 9yXIbJPMoaNo909CzzsmwoZRrcbDfOJel+zQUi23SJiWQS956hXh66LqorG3qGRTEkQI xu6w== 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=0fyH5mQDUsURP1bl+/KKQb8XEWjHUh2li5zD+MUTlro=; b=CEabo0oZX5uEzNtm4tAIF7w1mN1/LdSXRc12OlFX4wImzAmf8mW8NM6rGSb5GIDh6p D6RHd0GumAe3woXxTXr6FEjsGbRXIqw2CTeBxBsKTItOhPvjDUunIm4ae1OORk+1pvRM HbdnAPX3p4/5JkfD5wknu1FI5x63ZQ2MaKhcWgqmV+ic3YaFq8Qe0T41AJzdlAz8QJXN f9Oke/1mKlr8VGVyfKMJ1XterQAhDPcC2c5IWfLd9qWzBkTf5Cwfd2RCHi46DFdV8WWb TfCrdplh/RFLbI28WP/WbosKBTZZCR6/Gvp24mR5tiRQyoUdvqZGn8r/z0EwvPYpE/0b DjnQ== X-Gm-Message-State: AOAM533CLs31DQLp4MSudrEC6Jj8r06XcoFmu1gCt1GKLUq/xYZUuzDD 1aJzAIAv6kvlEalaH7AWiQy/VeufWkZB1S4/XUUqJAfj8h8= X-Google-Smtp-Source: ABdhPJyTn/w14SxLiEOrLcpnvWNJlMh92/qCk5tHXraFoadBvJc+1xvO/Q78Q/wuZ5ibpP4kcaR9dRC6LRPzdggIG1M= X-Received: by 2002:a05:6512:3b7:: with SMTP id v23mr6130827lfp.10.1597619076203; Sun, 16 Aug 2020 16:04:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 16 Aug 2020 16:04:00 -0700 Message-ID: To: Francis Pouatcha Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000086098605ad06adef" 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: Sun, 16 Aug 2020 23:04:45 -0000 --00000000000086098605ad06adef Content-Type: text/plain; charset="UTF-8" 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/ > --00000000000086098605ad06adef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francis

I was intentional in stating= 1.3 that it is human interactions. The connection lines are '+=C2=A0+= =C2=A0+' rather than '-----' to indicate that it is a human int= eraction rather than a protocol between roles. We can't specify how a h= uman interaction works, but we can show when they might occur relative to t= he 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 technica= lly specified. The User and RO are not roles in the protocol, but are entit= ies in the trust model.

I debated keeping the inte= ractions abstract and not stating=C2=A0"what" happened in each in= teraction, but thought that might be confusing at this stage or our discuss= ions.

Since it is just an interaction between huma= n and software, we can have the User authenticate to the GC as well as auth= orize (provide consent), and have no interaction at the GS. We would need t= o define how to represent the authorization and the consent for the GC to p= ass to the GS, but the roles and entities stay the same. The trust model do= es change though.

/Dick

<= br>




=
On Sun= , Aug 16, 2020 at 3:46 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,= =C2=A0my 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 th= is "End User" interaction and not "human ...". It is no= t about having a human, but a terminating edge of the protocol. An "En= d User" can be either human on an IOT device or a car or ...

Pa= rticipant: User -> "Requesting Party"
I will still insist o= n replacing the word "User" with a role name. Maybe "Request= ing Party" as used by UMA.

Participant: "Resource Controll= er". In past discussions there was a consensus on using "Resource= Controller" instead.

(B) I which the GS never interacts with t= he "Requesting Party" in a matter of obtaining a grant to a resou= rce (many reasons: privacy, confidentiality, abstraction, ...). Generally t= he GS will need information (claims) about the "Requesting Party"= to proceed with the authorisation decision. In this case, the GS can instr= uct the GC to obtain those claims. In some cases, claims on the "Reque= sting Party" will be obtained from another "Authorization Server&= quot; (AS). The word AS is intentionally chosen here. In this same login, t= he 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 ca= se the Requesting Party, and the Resource Controller).

The result ca= n look like the modified diagram below. With this we can address some priva= cy concerns 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-A= S =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=A0Reso= urce =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 +------------+

(B0, B1) replace (B). Occur inside step (3), GS asks GC to collec= t the claims. GC contacts RP-AS to negotiate those=C2=A0claims. But it is i= mportant to mention that those Claims-RP are not the target Grant being neg= otiated for the resource access. They are generally=C2=A0used by GS (and la= ter RS) as input into performing authz decisions.

(C0, C1) re= place (C). They occur=C2=A0after step (3) (Beware of the difference=C2=A0to= Bs that occur=C2=A0inside 3). This separation address the Big Brother prob= lem we have been discussing in the list.

Essential is to ment= ion that in an instantiation of this model for oAuth for example:
- GS, RP-AS and RC-AS might be the same en= tity.
- RP and RC might refer to = the same "End User".=C2=A0

Off-topic: The splitting of GS and AS was suggested in some discuss= ions on the mailing list. But we have no mean yet to isolate good inputs fo= r 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 wha= t I would rather call the trust framework. The purpose of the trust framewo= rk will be to address topics mentioned in this section. There is still a lo= t of discussion needed to have a structure for this section.


1.5=
I suggest again we replace Human with "End User" and still ma= ke them roles. This is:
Terminology (Are all roles)
=C2=A0 -> Thes= e roles can be borne by End Users
=C2=A0 =C2=A0 =C2=A0-> Requesting P= arty (RP)
=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 qu= alified review of section 2++.

Best regards
<= div>/Francis

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

I ju= st 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=C2=A0Authorizations -> Access
  • An Access contain= s=C2=A0an array of RAR objects now
  • Reworked diagram an intro to foc= us 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 tha= t may be adopted by the proposed GNAP working group. Please refer to this d= ocument as:

XAuth

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

Th= is document describes the core Grant Negotiation and Authorization Protocol= (GNAP). The protocol supports the widely deployed use cases supported by O= Auth 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_Advanced= ]=C2=A0and JOSE Authentication=C2=A0[JOSE_= Authentication]=C2=A0that describes the JOSE mechanisms for clie= nt authentication.

The technology landscape has changed since OAuth 2.0 was initi= ally drafted. More interactions happen on mobile devices than PCs. Modern b= rowsers now directly support asymetric cryptographic functions. Standards h= ave emerged for signing and encrypting tokens with rich payloads (JOSE) tha= t are widely deployed.

GNAP simplifies the overall architectural model, takes adv= antage of today's technology landscape, provides support for all the wi= dely deployed use cases, offers numerous extension points, and addresses ma= ny of the security issues in OAuth 2.0 by passing parameters securely betwe= en parties rather than via a browser redirection.

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

The suggest= ed pronunciation of GNAP is "guh-nap".

1.1.=C2=A0T= he Grant

The Gr= ant 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 Se= rver negotiate the Grant. The Grant Server acquires authorization to grant = the Grant to the Grant Client. The Grant Server then returns the Grant to t= he Grant Client.

The Grant Request may contain information about the User, th= e Grant Client, the interaction modes supported by the Grant Client, the re= quested 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: t= he 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. Th= is step is not in scope for this document.

(2) The GC makes a Grant request t= o the GS (Create Grant=C2=A0Section 3.2). How the GC authenti= cates 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= =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 th= is document.

1.3.=C2=A0Hu= man Interactions

Below is when the human interactions may occur in the protocol:<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.3-2" style=3D"text-decoration-line:none;color:rgb(102,102,102)" targe= t=3D"_blank">

    =
+--------+                               +------------+
    |  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. The addition of the human int= eractions (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 w= hat the RS requires from a GS for resource access

(2) The GC makes a Grant re= quest to the GS

(3) The GC and GS may negotiate the Grant

(B) The GS ma= y interact with the User for grant authorization

(C) The G= S may interact with the RO for grant authorization<= /a>

(4) The GS retu= rns a Grant to the GC

(5) The GC accesses resources at the RS

(6) The RS ev= aluates access granted by the GS to determine access granted to the GC

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

1.4.=C2=A0= 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=C2=A0(CO) - the legal entity t= hat owns the Grant Client.
  • Grant Server Owner=C2=A0(GSO) - the = legal entity that owns the Grant Server.
  • Claims Issuer=C2=A0(Is= suer) - a legal entity that issues identity claims about the User. The Gran= t 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<= /a>

(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.=C2=A0Terminology

Roles

  • Grant Client=C2=A0(GC)

    • may want ac= cess to resources at a Resource Server
    • may be interacting with a User = and want identity claims about the User
    • requests the Grant Service to g= rant resource access and identity claims
    <= /li>

  • 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 interact= ion is required with the User
    • acquires authorization from the User befor= e granting identity claims to the GC
    • acquires authorization from the RO = before granting resource access to the GC
    • grants resource access and ide= ntity claims to the GC

  • Resource Server=C2=A0(RS)

    • =
    • expresses what the GC mus= t obtain from the GS for access through documentation or an API. This is no= t in scope for this document
    • verifies the GS granted access to the GC, w= hen the GS makes resource access requests
    =

Human= s

  • User=

    • the person interacting with the Grant Client.
    • has delegated access t= o 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 r= esource access management to the GS.
    • may be the User, or may be a diff= erent entity that the GS interacts with independently.<= /a>

= Reused Terms

  • access token=C2=A0- an access 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 Claim 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 Register= ed Client as defined in=C2=A0[RFC6749]=C2=A0Section = 2.2.
  • = ID Token=C2=A0- an ID Token as defined in=C2=A0[O= IDC]=C2=A0Section 2. ID Tokens are issued by the GS. The GC uses= an ID Token to authenticate the User.
  • NumericDate=C2=A0- a Num= ericDate as defined in=C2=A0[RFC7519]=C2=A0Section 2= .
  • authN=C2=A0- short for authentication.
  • authZ=C2= =A0- short for authorization.

New Terms

  • GS URI=C2=A0- the endpoint at= the GS the GC calls to create a Grant, and is the unique identifier for th= e GS.
  • Registered Client=C2=A0- a GC that has registered with th= e GS and has a Client ID to identify itself, and can prove it possesses a k= ey 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 i= nteracting 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 it is the same instance of th= e GC on subsequent requests.. The GS MAY return a Dynamic Client a Client H= andle for the Dynamic Client to identify itself in subsequent requests. A s= ingle-page application with no active server component is an example of a D= ynamic Client.
  • Client Handle=C2=A0- a unique identifier at the = GS for a Dynamic Client for the Dynamic Client to refer to itself in subseq= uent requests.
  • Interaction=C2=A0- how the GC directs the User t= o 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 claim= s and/or resource access the GS has granted to the Client. The GS MAY inval= idate a Grant at any time.
  • Grant URI=C2=A0- the URI that repres= ents the Grant. The Grant URI MUST start with the GS URI.
  • Access=C2=A0- the access granted by the RO to the GC and contains an access toke= n. 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 A= ccess 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
--00000000000086098605ad06adef-- From nobody Sun Aug 16 16:38:31 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 B50493A0A92 for ; Sun, 16 Aug 2020 16:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 WQUkEvo5g1Md for ; Sun, 16 Aug 2020 16:38:26 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0: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 2A2FE3A0A86 for ; Sun, 16 Aug 2020 16:38:26 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id x24so12087059otp.3 for ; Sun, 16 Aug 2020 16:38:26 -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=p32eC9rcJ1m2ZaqwDeRZobL16734IRMeiNIZZDPp4oo=; b=S6Qpit8t3z8jNC9DcX6IfX+1e8fE2z9FQHe8yuMUZtqGBC3Q/yo16WqV2ryQq5o7LG ZrrjYDAstIQQ0oikRoD/Vk2g5O98Kp0L1IwZz0+2GrSL9d908Fj4LyeL9OGwij7w2yG1 hPCFbQGYIQtLrE+zZ8uPliRnchta3AzBvsN5dbXjZ9yaZFDRBKx0lW/B1BCKau9AbIpo Z7ja+0O1KWzE5tMtbDcsRXym51/SvY/bGAw+LRJANl+8R6wszllq9MTubMUyZRu8UguH 7ahJLEGUSeHE7PYeYAzQ36ww+7PyqaCJJT4jlNteturlXuz7Gt0UNy0spvDXcahp0i2D elkQ== 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=p32eC9rcJ1m2ZaqwDeRZobL16734IRMeiNIZZDPp4oo=; b=pWUxlNzKt3+q3+min9UjmyJXsOW8toxYfuXusGt8NkKQj2L0Kl2Ct7qhUdlzozOXoX HTKPKysOgE4bXl/9+EBGtIDA64xhQzHtgumdbGcFY1n3ZjZgxu5DJLGIKW2XFaRXii+h ZnmcOShroPfwm/TbWs1aY020v+VKlv+Nmsb6oEOQOrvz8y0odKw84l5QQV/EjB3n08pQ lM2HE7kqc57mdXUngKeHNUgZtWe7a9iFIbGMpGO40hEFd/+38C5W7L9hUS/ZjYYdoY+z 1UuEIsjpBIjLjFA6EywpVAb+TMG4j5KlReRl4rHry6Y+0BgjvIIY8QPb8OguxyVdnBfd 43Rg== X-Gm-Message-State: AOAM532xeE0BvB2YSjEiPPX/DwPrENffUfJACttOX7VcLyUsQVQJLHxg /ICiGtWmO8DIkhuBQBkbvcz8q5e5WvXprH1VZKo= X-Google-Smtp-Source: ABdhPJyL7Ei6CkIQjtLklDv1oTv7Xegu7J7xyzs3hN3FX3hdyHTYf4Va2cZtwsPSoAKu/j6KAf5XusugCpVQ96SIPc0= X-Received: by 2002:a9d:84c:: with SMTP id 70mr9025301oty.358.1597621105133; Sun, 16 Aug 2020 16:38:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Sun, 16 Aug 2020 16:38:13 -0700 Message-ID: To: Francis Pouatcha Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000750bf305ad072692" 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: Sun, 16 Aug 2020 23:38:30 -0000 --000000000000750bf305ad072692 Content-Type: text/plain; charset="UTF-8" i disagree - end user needs to be a human = use term like subject or endpoint if you want a non-human Peace ..tom 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000750bf305ad072692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i disagree - end user needs to be a human =3D use term lik= e subject or endpoint if you want a non-human
Peace ..tom



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

I just pushed an updated version of XAuth:

https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.h= tml

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

/Dick
<= /div>

1.=C2=A0Introduction

EDITOR NOTE

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

XAuth

The use of GNAP in this documen= t is not intended to be a declaration of it being endorsed by the GNAP work= ing group.

This document describes the core Grant Negotiation and Authorizat= ion Protocol (GNAP). The protocol supports the widely deployed use cases su= pported 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. Relate= d documents include: GNAP - Advanced Features=C2=A0[GNAP_= Advanced]=C2=A0and JOSE Authentication=C2=A0[JOSE_Authentication]=C2=A0that describes the JOSE mechanis= ms for client authentication.

The technology landscape has changed since OAuth 2.= 0 was initially drafted. More interactions happen on mobile devices than PC= s. 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 a= ddresses many of the security issues in OAuth 2.0 by passing parameters sec= urely between parties rather than via a browser redirection.

While GNAP is not ba= ckwards compatible with OAuth 2.0, it strives to minimize the migration eff= ort.

T= he suggested pronunciation of GNAP is "guh-nap".

1.1.=C2=A0<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name= -the-grant" style=3D"text-decoration-line:none;color:rgb(34,34,34)" target= =3D"_blank">The Grant

The Grant is at the center of the protocol between a client and a se= rver. A Grant Client requests a Grant from a Grant Server. The Grant Client= and Grant Server negotiate the Grant. The Grant Server acquires authorizat= ion to grant the Grant to the Grant Client. The Grant Server then returns t= he Grant to the Grant Client.

The Grant Request may contain information about= the User, the Grant Client, the interaction modes supported by the Grant C= lient, the requested identity claims, and the requested resource access. Ex= tensions may define additional information to be included in the Grant Requ= est.

1.2.=C2=A0Protocol 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 determine what the RS requires from a GS for resource access. Th= is step is not in scope for this document.

(2) The GC makes a Grant request t= o the GS (Create Grant=C2=A0Section 3.2). How the GC authenti= cates 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= =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 th= is document.

1.3.=C2=A0H= uman Interactions

The Grant Client may be interacting with a human end-user (User), and th= e 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 Resour= ce 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. The addition of the human int= eractions (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 w= hat the RS requires from a GS for resource access

(2) The GC makes a Grant re= quest to the GS

(3) The GC and GS may negotiate the Grant

(B) The GS ma= y interact with the User for grant authorization

(C) The G= S may interact with the RO for grant authorization<= /a>

(4) The GS retu= rns a Grant to the GC

(5) The GC accesses resources at the RS

(6) The RS ev= aluates access granted by the GS to determine access granted to the GC

Al= ternatively, the Resource Owner could be a legal entity that has a software= component that the Grant Server interacts with for Grant authorization. Th= is 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(I= ssuer) - a legal entity that issues identity claims about the User. The Gra= nt Server Owner may be an Issuer, and the Resource Owner may be an Issuer.<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.4-2.3" style=3D"text-decoration-line:none;color:rgb(102,102,102)" tar= get=3D"_blank">

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<= /a>

(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.=C2=A0Terminology

Roles

  • Grant Client=C2=A0(GC)

    • may want ac= cess to resources at a Resource Server
    • may be interacting with a User = and want identity claims about the User
    • requests the Grant Service to g= rant resource access and identity claims
    <= /li>

  • 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 interact= ion is required with the User
    • acquires authorization from the User befor= e granting identity claims to the GC
    • acquires authorization from the RO= before granting resource access to the GC
    • grants resource access and id= entity claims to the GC

  • Resource Server=C2=A0(RS)<= /a>

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

    Huma= ns

    • User=

      • the person interacting with the Grant Client.
      • has delegated access t= o 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 th= e GS.
      • may be the User, or may be a different entity that the GS intera= cts with independently.

    Reused Terms

    • access token=C2=A0= - an access token as defined in=C2=A0[RFC6749]=C2=A0= Section 1.4.. An GC uses an access token for resource access at a RS.
    • = Claim=C2=A0- a Claim 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=A0Sect= ion 2. ID Tokens are issued by the GS. The GC uses an ID Token to authentic= ate the User.
    • NumericDate=C2=A0- a NumericDate as defined in=C2= =A0[RFC7519]=C2=A0Section 2.
    • authN=C2=A0= - short for authentication.
    • authZ=C2=A0- short for authorizatio= n.

    New Terms

    • GS URI=C2=A0- the endpoint at the GS the GC calls to cr= eate a Grant, and is the unique identifier for the GS.
    • Registered Clie= nt=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 Registere= d Clients can request.. A Registered Client MAY be interacting with a User.=
    • Dynamic Client=C2=A0- a GC that has not been previously regist= ered with the GS, and each instance will generate it's own asymetric ke= y pair so it can prove it is the same instance of the GC on subsequent requ= ests.. The GS MAY return a Dynamic Client a Client Handle for the Dynamic C= lient to identify itself in subsequent requests. A single-page application = with no active server component is an example of a Dynamic Client.
    • Cli= ent Handle=C2=A0- a unique identifier at the GS for a Dynamic Clie= nt for the Dynamic Client to refer to itself in subsequent requests.
    • Int= eraction=C2=A0- how the GC directs the User to interact with the G= S. 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 acc= ess 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 G= rant URI MUST start with the GS URI.
    • Access=C2=A0- the access g= ranted by the RO to the GC and contains an access token. The GS may invalid= ate an Access at any time.
    • Access URI=C2=A0- the URI that repre= sents the Access the GC was granted by the RO. The Access URI MUST start wi= th 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
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000750bf305ad072692-- From nobody Sun Aug 16 16:59:10 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 934633A1213 for ; Sun, 16 Aug 2020 16:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=openconsent.onmicrosoft.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 J4e4-XV52QtK for ; Sun, 16 Aug 2020 16:59:03 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2121.outbound.protection.outlook.com [40.107.92.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DC83A0B55 for ; Sun, 16 Aug 2020 16:59:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GZ9O/Fm0r8XcfJJLZmu2LsuFBnviex65f4BIHb/Ym0zxJrMm/cMr9pYAR28n/rWVV7AHqjXwomwGZIzqxb7AmwC3BGwqY1vmkQIOYxypAyS7PzluDzZRqRyei46e6yOvP1VvkJl74cPg8+QMnO/zsP3iO710YvkPMDmXN9fohkFwKJEOP3bViAkYEb39sx3Ud0D45NMksIdy+YRw7VfRIJaEPyKscyaTcHykRo381Elw242MxAokGXLiwASuztKKahmcQsjylXHZijeAFzCQe6ZJL5/be4SqsH/IhWoh9P8WskN2Yibvnle3XnO64ONjf1D8XlxJBsQWlCfUTF7stQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0AKtZT9SxkexIo+ECvvki0xyBjCxeGzpHr77/m8it88=; b=M2bcDFDA2sYEuds/JPVdlp2kOaMSvRJhxkv5eB6QomVTsD3CofbuFUufqpx42Mrkp1C3FLNuQ0fSRatBl0Qq4VJRlxfkjASnFBHSCug5HVZ32zgCawv9RBdUkFaistCArq6ICTEDm+xw6oKmv9qXGymYS2obtM5+ehr9nVXA6l58Uyntz1K60j+NtdMIARYLy9CmcWpyXXtLwkZRrafFik0x+0L9Wn56H+t53wspKbRiRAyLgEx///iuIrvN6d4Dz/MDlN490lthU/40nbVDFNrAKL36p8FgVE7CkNWk+Zjlrjxl2oEaebqRcn6jXmtq3S1CZwwWiBoiEVfkYHzrkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=openconsent.com; dmarc=pass action=none header.from=openconsent.com; dkim=pass header.d=openconsent.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openconsent.onmicrosoft.com; s=selector1-openconsent-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0AKtZT9SxkexIo+ECvvki0xyBjCxeGzpHr77/m8it88=; b=girW21PghZ8wrvsbJ38FV4NN2SX77XsePnYN62skjSDKrqQcUnLKxDxVUYDN6IGnbzf2CsryGeaEbljO3rFnbhh8Gyn9LhaQmVo6wF6gVF+HQl4mJn/6cDz+124OYrka4kkOhoybEJSGzdOXYDS6vHkCjwAevfwpfS3ZeeFgqXHnRXcXVgX5MiXlTFetnwusy+bXOkSsTeDzwfUGyuclToPLBPq3SgkG6zVVBprE6Gqnkx3fsVp3ihbdUHLPXjkSYX8jeXEERgx7jjuwuclARxg1dZ2csSheRqxMDbdj6mLEW/nFgfLgiUGS7Mf5aBkutfIo5tOEKPOBVHjhq14Isg== Received: from CY4PR14MB1752.namprd14.prod.outlook.com (2603:10b6:903:15b::16) by CY4PR1401MB2039.namprd14.prod.outlook.com (2603:10b6:910:24::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Sun, 16 Aug 2020 23:58:55 +0000 Received: from CY4PR14MB1752.namprd14.prod.outlook.com ([fe80::48ec:df78:c9cf:5b25]) by CY4PR14MB1752.namprd14.prod.outlook.com ([fe80::48ec:df78:c9cf:5b25%3]) with mapi id 15.20.3283.027; Sun, 16 Aug 2020 23:58:55 +0000 From: Mark Lizar To: Tom Jones , Francis Pouatcha CC: GNAP Mailing List , Dick Hardt Thread-Topic: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introduction Thread-Index: AQHWdB8pD0Ff2eMBkkiD+DL+ZQG9f6k7ZF6AgAAEkh4= Date: Sun, 16 Aug 2020 23:58:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=openconsent.com; x-originating-ip: [162.253.71.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b674cee1-1816-4641-53f3-08d8424055a4 x-ms-traffictypediagnostic: CY4PR1401MB2039: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i7yKYkRoORDgJmHEM4R9jH7qy1VffeuFoehOmFjtWrn+FFyzYOlfZqxv1/qsKYP1JHE3fjeCGB6OHwe1jBHPWGFh99sxFn6hq5WlkPvRIJ/9+NqbsI6zQ6fBKl/oAVi00pk83Rfd4BoEkVy3V55GLwiPpOmy5ZBUsNsqpvshu4g2MqkZOTb7GODPoc4R527x4x7gdFFmXdoaQ7tVblGMTGLtVzJewHVv/58OSfoQl0VQwUp0BQ86K/kEldmC0RHDqRVEeT5KhvaNXqBZo+EBQEjoB8YwhY3dnvU0RWIOySQVwNWrG1tMh/ItCg+rMfA2ByjzwE2xyprkognTomg/mn2OZ4YhQI7IVFObGNYucSYZSmP4xvaGymklBcwqVBvt4g0bo6IBXbEb5YwmTb8AuA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR14MB1752.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(34096005)(136003)(366004)(396003)(346002)(39830400003)(376002)(966005)(55016002)(76116006)(66574015)(26005)(83380400001)(316002)(66446008)(66556008)(2906002)(66946007)(186003)(9686003)(71200400001)(64756008)(21615005)(66476007)(30864003)(15650500001)(478600001)(83080400001)(110136005)(4326008)(33656002)(8676002)(8936002)(7696005)(54906003)(86362001)(166002)(52536014)(53546011)(6506007)(45080400002)(5660300002)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: mc1/Wi1Si4XAxTZC/psyp6WA2lQEYrjL3hUyewdRjPA3rQ2sMFqWuSg+14TXpp1VVuD8JCCyufsUGNe2/txIU/muZI/Ce3MeTnGuTPis4dZX2VFVuQNV/3B3yUL/IFuJYI1RiqkQYCsIh7CRqQb6oRM46TMda348Z9h1owOThsqIiVDQu8Nour1v5az1Wvfvng+Lsyz+yyqbxnQjn0JPGeswEgqkVGQr83L0PjJc3S0Y05MPF4BLsMbJP9eqRO03IGfOKpSpSBvadp8ebFQuoFiCpeE31mNR77pHwvb+ABJGG6fLhpARYTKjr/Zj+8KOU8JCsGFHzAotMf0UKkTgxwCob9B78KPtIyFwerZPA/Kk6rffN1R1zPoysyLaHYKyzt2OdIFnp58n70lAllYcGIorZXapFMnnHBoD4pdrNrEMFlDo9cGnV5Cp6ng8Gm8Fc57Iggo9tm+lP8m/ns1c2RKbtRoiRAW67xRrWf6c4VyC+xMv1RPFZ79KVBTHWBCYMbJlgWkSFyDsg/UgjAfh6sAn+xjUeX0MfwGLaTWHhWsFzifP1oaOBbgivliN9uZTqGeePiZuWbIIkrYXZCXEdyGZzf3nCe5dw4cEgYA2dAgT+7YASibuJEzsqwU0OvLGPjlZXriiNWnG1kiYmv28fQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1752A444DB20E509F1B74357DA5E0CY4PR14MB1752namp_" MIME-Version: 1.0 X-OriginatorOrg: openconsent.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR14MB1752.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b674cee1-1816-4641-53f3-08d8424055a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2020 23:58:55.4058 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d6e4f995-32e4-4f49-9949-0abe865e4152 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jlMBu1nyqXjXo6h8ZBQ7mFi3KeTWdX/Hr2h+k7lHmea3jTxlY/Ub4MuA2YZgLs8fXYA3x6nVCKNFAMb6DUQyIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1401MB2039 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: Sun, 16 Aug 2020 23:59:08 -0000 --_000_CY4PR14MB1752A444DB20E509F1B74357DA5E0CY4PR14MB1752namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable - consent is the human management of a permission grant the system manages = . +1 for not mixing human and system terms for the same endpoint. Get Outlook for iOS ________________________________ From: TXAuth on behalf of Tom Jones Sent: Sunday, August 16, 2020 7:38:13 PM To: Francis Pouatcha Cc: GNAP Mailing List ; Dick Hardt Subject: Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introdu= ction i disagree - end user needs to be a human =3D use term like subject or endp= oint if you want a non-human Peace ..tom 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 a= bout 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 "R= equesting Party" as used by UMA. Participant: "Resource Controller". In past discussions there was a consens= us 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 t= he "Requesting Party" to proceed with the authorisation decision. In this c= ase, the GS can instruct the GC to obtain those claims. In some cases, clai= ms on the "Requesting Party" will be obtained from another "Authorization S= erver" (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. En= d 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 addre= ss 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 clai= ms. GC contacts RP-AS to negotiate those claims. But it is important to men= tion 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 int= o performing authz decisions. (C0, C1) replace (C). They occur after step (3) (Beware of the difference t= o 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 fo= r 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 pa= ges (like use cases). 1.4: The Trust model introduces what I would rather call the trust framework. Th= e purpose of the trust framework will be to address topics mentioned in thi= s section. There is still a lot of discussion needed to have a structure fo= r 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 necessa= ry 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 ro= les 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 prop= osed 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 Protoc= ol (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 [G= NAP_Advanced] and JOSE Authentication [JOSE_Authentication] that d= escribes 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 d= irectly support asymetric cryptographic functions. Standards have emerged f= or 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 cas= es, offers numerous extension points, and addresses many of the security is= sues in OAuth 2.0 by passing parameters securely between parties rather tha= n via a browser redirection. While GNAP is not backwards compatible with OAuth 2.0, it strives to minimi= ze 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 Gr= ant Server negotiate the Grant. The Grant Server acquires authorization to = grant the Grant to the Grant Client. The Grant Server then returns the Gran= t 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 identit= y claims, and the requested resource access. Extensions may define addition= al 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 t= he GC authenticates to the GS is not in scope for this document. One mechan= ism 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 t= o 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 G= rant Client may need to get authorization to release the Grant from the Use= r, 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 int= eractions (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 t= o the GC Alternatively, the Resource Owner could be a legal entity that has a softwa= re 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 entit= ies 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 Serve= r. * Claims Issuer (Issuer) - a legal entity that issues identity claims a= bout the User. The Grant Server Owner may be an Issuer, and the Resource Ow= ner may be an Issuer. These three entities do not interact in the protocol, but are trusted by th= e 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 t= he CO (B) User trusts the CO to act in the User's best interest with the Grant th= e 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 c= laims * Grant Server (GS) * accepts Grant requests from the GC for resource access and identit= y claims * negotiates the interaction mode with the GC if interaction is requ= ired with the User * acquires authorization from the User before granting identity clai= ms 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 d= ocumentation or an API. This is not in scope for this document * verifies the GS granted access to the GC, when the GS makes resour= ce access requests Humans * User * the person interacting with the Grant Client. * has delegated access to identity claims about themselves to the Gr= ant Server. * may authenticate at the GS.. * Resource Owner (RO) * the legal entity that owns resources at the Resource Server (RS).<= https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.= 2.2.1> * has delegated resource access management to the GS. * may be the User, or may be a different entity that the GS interact= s 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 i= s the unique identifier for the GS. * Registered Client - a GC that has registered with the GS and has a Cl= ient 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 Re= gistered Clients can request.. A Registered Client MAY be interacting with = a User. * Dynamic Client - a GC that has not been previously registered with th= e 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 MA= Y return a Dynamic Client a Client Handle for the Dynamic Client to identif= y itself in subsequent requests. A single-page application with no active s= erver component is an example of a Dynamic Client. * Client Handle - a unique identifier at the GS for a Dynamic Client fo= r the Dynamic Client to refer to itself in subsequent requests. * Interaction - how the GC directs the User to interact with the GS. Th= is document defines the interaction modes: "redirect", "indirect", and "use= r_code" in Section 5. * Grant - the user identity claims and/or resource access the GS has gr= anted to the Client. The GS MAY invalidate a Grant at any time. * Grant URI - the URI that represents the Grant. The Grant URI MUST sta= rt with the GS URI. * Access - the access granted by the RO to the GC and contains an acces= s 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/ -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --_000_CY4PR14MB1752A444DB20E509F1B74357DA5E0CY4PR14MB1752namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
- consent is the human management of a permi= ssion grant the system manages .   +1 for not mixing human and sy= stem terms for the same endpoint.  =

Get Outlook for iOS
From: TXAuth <txauth-bou= nces@ietf.org> on behalf of Tom Jones <thomasclinganjones@gmail.com&g= t;
Sent: Sunday, August 16, 2020 7:38:13 PM
To: Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>
Cc: GNAP Mailing List <txauth@ietf.org>; Dick Hardt <dick.h= ardt@gmail.com>
Subject: Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked = introduction
 
i disagree - end user needs to be a human =3D use term lik= e subject or endpoint if you want a non-human
Peace ..tom


On Sun, Aug 16, 2020 at 3:46 PM Fra= ncis Pouatcha <fpo=3D40ad= orsys.de@dmarc.ietf.org> 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 prot= ocol. 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, confid= entiality, abstraction, ...). Generally the GS will need information (claim= s) 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 mi= ght 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 addre= ss some privacy concerns that are being discussed on the list.

    +-------------+             &nb= sp;          +----------------+
    | Requesting  |            = ;            |  Resource     &= nbsp;|
    | Party (RP)  |            = ;            | Controller (RC)|
    +-------------+             &nb= sp;          +----------------+
        +     +         &= nbsp;                   +
        +      +       &n= bsp;                   +
       (A)     (B1)       &nbs= p;              (C1)
        +        +     &n= bsp;                 +
        +.        +     &= nbsp;               +
        +       +--------+    =   +--------+
        +       | RP-AS  |   &= nbsp;   | RC-AS  |
        +       |       &= nbsp;|       |        |
        +       +--------+    =   +--------+
        +         +     &= nbsp;            +  
        +       (B0)      = ;          +    
        +       +       &= nbsp;        (C0)  
    +--------+ +              =    +          +------------+
    | Grant  | - - - -(1)- - - - + - - - - ->|  Reso= urce  |
    | Client |               &= nbsp;  +            |   Server &nbs= p; |
    |  (GC)  |       +---------------+ &= nbsp;     |    (RS)    |
    |        |--(2)->|     Grant=     |       |           =  |
    |        |<-(3)->|     Se= rver    |- (6) -|            |
    |        |<-(4)--|      = ;(GS)     |       |         &n= bsp;  |
    |        |       +--------= -------+       |            |<= br>     |        |         &n= bsp;                     = |            |
    |        |--------------(5)-------------&= gt;|            |
    +--------+               &= nbsp;               +------------+

(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 ta= rget Grant being negotiated for the resource access. They are generally used by GS (and later RS) as input into pe= rforming authz decisions.

(C0, C1) replace (C). They occur after s= tep (3) (Beware of the difference to Bs that occur inside 3). Thi= s separation address the Big Brother problem we have been discussing in the= list.

Essential is to mention that in an instantiat= ion of this model for oAuth for example:
- GS, RP-AS and RC-AS might be the same entit= y.
- 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 pa= ges (like use cases).

1.4:
The Trust model introduces what I would rather call the trust framework. Th= e purpose of the trust framework will be to address topics mentioned in thi= s section. There is still a lot of discussion needed to have a structure fo= r this section.


1.5
I suggest again we replace Human with "End User" and still make t= hem 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 necessa= ry for a qualified review of section 2++.

Best regards
/Francis

On Sat, Aug 15, 2020 at 7:03 PM Dic= k Hardt <dick.= hardt@gmail.com> wrote:
Hello

I just pushed an updated version of XAuth:


Highlights:
  • renamed Client -> Grant Client
  • Introduced Client Owner, Gran= t Server Owner as new entities
  • renamed Authorizations -> Ac= cess
  • An Access contains an array of RAR objects now
  • Re= worked 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 Protoc= ol (GNAP). The protocol supports the widely deployed use cases supported by= OAuth 2.0 [RFC6749] & [RFC6750], OpenID Connect [OIDC] - an extension of OAu= th 2.0, as well as other extensions. Related documents include: GNAP - Advanced Features [GNAP_Advanced] and JOSE Authentication [JOS= E_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 d= irectly support asymetric cryptographic functions. Standards have emerged f= or 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 cas= es, offers numerous extension points, and addresses many of the security is= sues 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 minimi= ze 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 Gr= ant 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 identit= y claims, and the requested resource access. Extensions may define addition= al 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 Se= ction 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 Sect= ion 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 t= o 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 G= rant Client may need to get authorization to release the Grant from the Use= r, 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 addi= tion of the human interactions (A) - (C) are bolded&n= bsp;below.

(A) The User is interacting with a GC, and the GC needs resource ac= cess 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 t= o the GC

Alternatively, the Resource Owner could be a legal entity that has a softwa= re 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 entit= ies that are part of the trust model:

  • Client Owner (CO) - the legal entity that owns the Gr= ant Client.
  • Grant Server Owner (GSO) - the legal entity that owns= the Grant Server.
  • Claims Issuer (Issuer) - a legal entity that issues i= dentity 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 th= e 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 t= he CO

(B) User trusts the CO to act in the User's best interest with the Grant th= e 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)

  • Grant Server (GS)

    • accepts Grant requests from the GC for resource access and identity claims<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.5-2.2.2.1" target=3D"_blank" style=3D"text-decoration-line:none; colo= r:rgb(102,102,102)">
    • 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 G= C
    • grants resource access and identity claims to the GC

  • Resource Server (RS)

Humans

Reused Terms

New Terms

  • GS URI - the endpoint at the GS the GC calls to creat= e 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 ke= y that is linked to the Client ID. The GS may have different policies for w= hat different Registered Clients can request.. A Registered Client MAY be interacting with a User.
  • Dynamic Client - a GC that has not been previously re= gistered with the GS, and each instance will generate it's own asymetric ke= y pair so it can prove it is the same instance of the GC on subsequent requ= ests.. The GS MAY return a Dynamic Client a Client Handle for the Dynamic Client to identify itself in subsequent re= quests. A single-page application with no active server component is an exa= mple of a Dynamic Client.
  • Client Handle - a unique identifier at the GS for a D= ynamic Client for the Dynamic Client to refer to itself in subsequent reque= sts.
  • Interaction - how the GC directs the User to interact= with the GS. This document defines the interaction modes: "redirect&q= uot;, "indirect", and "user_code" in Section 5.
  • Grant - the user identity claims and/or resource acce= ss the GS has granted to the Client. The GS MAY invalidate a Grant at any t= ime.
  • Grant URI - the URI that represents the Grant. The Gr= ant URI MUST start with the GS URI.
  • Access - the access granted by the RO to the GC and c= ontains an access token. The GS may invalidate an Access at any time.
  • Access URI - the URI that represents the Access the G= C was granted by the RO. The Access URI MUST start with the GS URI.. The Ac= cess 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
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--_000_CY4PR14MB1752A444DB20E509F1B74357DA5E0CY4PR14MB1752namp_-- From nobody Sun Aug 16 19:38:03 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 35B643A12FA for ; Sun, 16 Aug 2020 19:38:01 -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 66WS2Ygm18VO for ; Sun, 16 Aug 2020 19:37:56 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 4140D3A12F6 for ; Sun, 16 Aug 2020 19:37:56 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id r4so13370799wrx.9 for ; Sun, 16 Aug 2020 19:37:56 -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=DxQNz9MHlJMiHJx3AVViANG1kwSQESdDtwSpfu8S7ts=; b=IAA2Q9Ihoz7gPaYtalrd5tuTbqPCrukv4Xd0kijPM+MZab4TscnJ5LycgeSb8GRQPG Qi/uheDPJ06jhIiU2Bsno6o2HFuNmeYvukpJ8LyWpNJvyPATTkqZ76zP74Gb+ASeglNf pFF2oA5LG8TgqoNE3QNKCY1nC59UVMdrlz+1E= 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=DxQNz9MHlJMiHJx3AVViANG1kwSQESdDtwSpfu8S7ts=; b=L3RL10C9dFUK6bGOOxFyVcd5UYbQdypRyV3LUgx7sFLmIJDML+DTMIEkO5iZt7EmHW 9SdXfchJabh7dv/1GIdGxkGZgzobv3yxffvc9mPpEbo8lXdIP7necoLvCE7RvFngeqAd /1BrwJHWTIQKTwlo12s7DTLmFQxBD8h7/imKXkMe2Y8HLBk5P/CvaEOeC2LwnBHiUtHE QVq6ONxC+gz9XuVReVzMBBcqo51rcME5xw47cdktSrZioR6eQDKKZnjDKBUr33z4FNUg LPlArGAnZOdxetQRvQaVg4N1xTXcNQOE2vlUldxVEDWFbTyLYB1Pgh3tAvbiEN0CcB2T 8sZg== X-Gm-Message-State: AOAM530z8zyZLfzfimLqMo8v5/yVGSUkvdnqUOPux4SWfIi+zwQu8SDD VJjv5LSBWIpzh50f8qIxEAdYhMGNvB7REo2zp6JLhQ== X-Google-Smtp-Source: ABdhPJwJSMYvbxyxhotXZqwo/yQ22NgfwONqvU1ROyHCUMn9AqO2kkJsSUjsNwpF2oJMRUeZIFnC3IfL3qZehJTJQyQ= X-Received: by 2002:adf:cc88:: with SMTP id p8mr12967045wrj.70.1597631874414; Sun, 16 Aug 2020 19:37:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Sun, 16 Aug 2020 22:37:42 -0400 Message-ID: To: Dick Hardt Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005b50ae05ad09a830" 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 02:38:01 -0000 --0000000000005b50ae05ad09a830 Content-Type: text/plain; charset="UTF-8" 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/ --0000000000005b50ae05ad09a830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

<= /div>
I was intentional in stating 1.3 that it is human interactions. T= he connection lines are '+=C2=A0+=C2=A0+' rather than '-----= 9; to indicate that it is a human interaction rather than a protocol betwee= n roles. We can't specify how a human interaction works, but we can sho= w 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=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 represent the author= ization and the consent for the GC to pass to the GS, but the roles and ent= ities stay the same. The trust model does change though.

/Dick







On Sun, Aug 16, 2020 at 3:46 PM Francis Po= uatcha <fpo@adorsys.= de> wrote:
Hello Dick,=C2=A0my feedback below:

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

1.3:
Title: Human Int= eraction -> End User Interaction
I would title this "End User&qu= ot; interaction and not "human ...". It is not about having a hum= an, 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 u= sed by UMA.

Participant: "Resource Controller". In past di= scussions there was a consensus on using "Resource Controller" in= stead.

(B) I which the GS never interacts with the "Requesting = Party" in a matter of obtaining a grant to a resource (many reasons: p= rivacy, confidentiality, abstraction, ...). Generally the GS will need info= rmation (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" wi= ll be obtained from another "Authorization Server" (AS). The word= AS is intentionally chosen here. In this same login, the path (C0, C1) bel= ow will not only return the RC consent, but might also return some claims o= n RC.

ASs provide authentication "of" and consent collecti= on "from" End Users. End users are in this case the Requesting Pa= rty, and the Resource Controller).

The result can look like the modi= fied diagram below. With this we can address some privacy concerns 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|
=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|<= br>=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) repl= ace (B). Occur inside step (3), GS asks GC to collect the claims. GC contac= ts RP-AS to negotiate those=C2=A0claims. But it is important to mention tha= t those Claims-RP are not the target Grant being negotiated for the resourc= e access. They are generally=C2=A0used by GS (and later RS) as input into p= erforming authz decisions.

(C0, C1) replace (C). They occur= =C2=A0after step (3) (Beware of the difference=C2=A0to Bs that occur=C2=A0i= nside 3). This separation address the Big Brother problem we have been disc= ussing in the list.

Essential is to mention that in an instan= tiation 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 Us= er".=C2=A0

Off-topic: Th= e splitting of GS and AS was suggested in some discussions on the mailing l= ist. But we have no mean yet to isolate good inputs for later reuse. This i= s 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 neede= d to have a structure for this section.


1.5
I suggest again w= e replace Human with "End User" and still make them roles. This i= s:
Terminology (Are all roles)
=C2=A0 -> These roles can be borne = by End Users
=C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)
=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 fund= amental 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 = <dick.hardt@gm= ail.com> wrote:
=
Hello

I just pushed an updat= ed version of XAuth:


Highlights:
  • renamed Client -> Grant Client
  • In= troduced 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 introdu= ction included below for your convenience

/Dick

1.=C2=A0Introduction<= /a>

EDITOR NOTE

This document captures a nu= mber of concepts that may be adopted by the proposed GNAP working group. Pl= ease refer to this document as:

XAuth

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

This document describes the core Grant = Negotiation and Authorization Protocol (GNAP). The protocol supports the wi= dely 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_Advanced]=C2=A0and JOSE Authenticatio= n=C2=A0[JOSE_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 fun= ctions. Standards have emerged for signing and encrypting tokens with rich = payloads (JOSE) that are widely deployed.

GNAP simplifies the overall architectural model, takes adv= antage of today's technology landscape, provides support for all the wi= dely deployed use cases, offers numerous extension points, and addresses ma= ny of the security issues in OAuth 2.0 by passing parameters securely betwe= en 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=A0Th= e Grant

The Grant is at the center= of the protocol between a client and a server. A Grant Client requests a G= rant from a Grant Server. The Grant Client and Grant Server negotiate the G= rant. The Grant Server acquires authorization to grant the Grant to the Gra= nt 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 requ= ested resource access. Extensions may define additional information to be i= ncluded in the Grant Request.

1.2.=C2=A0Protocol Roles

There are three roles in GNAP: the Grant Client (GC), t= he 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 determin= e what the RS requires from a GS for resource access. This step is not in s= cope for this document.

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

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

(4) The GS returns a Grant to the GC (Grant Response=C2= =A0Section 4.1).

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

(6) T= he 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=A0Hum= an Interactions

The Grant Client m= ay be interacting with a human end-user (User), and the Grant Client may ne= ed to get authorization to release the Grant from the User, or from the own= er of the resources at the Resource Server, the Resource Owner (RO)

Below is when the human int= eractions 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. 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)<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.3-5" style=3D"text-decoration-line:none;color:rgb(102,102,102)" targe= t=3D"_blank">

(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 a= uthorization

(4) The GS retu= rns a Grant to the GC

(5) The GC accesses resources at the RS

(6) The RS evaluates access granted by the GS to de= termine access granted to the GC

Alternatively, the Resource Owner could be a legal entity tha= t has a software component that the Grant Server interacts with for Grant a= uthorization. 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 tru= st model:

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

These three entities do not intera= ct 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 auth= orization before making a grant to the CO

(B) User trusts the CO to act in the User's best i= nterest 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 tru= sts the GSO to manage access to the RO resources

1.5.=C2=A0Terminology

Roles

=

  • Grant Client=C2=A0(G= C)

  • Grant Server=C2= =A0(GS)

    • accepts Grant requests from the GC for resource access and identi= ty claims
    • negoti= ates the interaction mode with the GC if interaction is required with the U= ser
    • acquires aut= horization from the User before granting identity claims to the GC
    • acquires authorization= from the RO before granting resource access to the GC<= /a>
    • 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 obtai= n from the GS for access through documentation or an API. This is not in sc= ope for this document
    • verifies the GS granted access to the GC, when the GS makes resource = access requests

Humans

  • User

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

  • Resource Owner=C2=A0(RO)

    • the legal entity that owns resources at the Resource Serve= r (RS).
    • has dele= gated 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 a= s 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 Claim as defined= in=C2=A0[OIDC]=C2=A0Section 5. Claims are issued by a = Claims Issuer.
    • C= lient 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.
    • Numer= icDate=C2=A0- a NumericDate as defined in=C2=A0[RFC75= 19]=C2=A0Section 2.
    • authN=C2=A0- short for authentication.
    • authZ=C2=A0- short = for authorization.

    New Terms

    • GS URI=C2=A0- the endpoint at the GS the GC calls to create a Grant, and is th= e 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 posses= ses a key that is linked to the Client ID. The GS may have different polici= es for what different Registered Clients can request. A Registered Client M= AY be interacting with a User.
    • Dynamic Client=C2=A0- a GC that has not been previo= usly registered with the GS, and each instance will generate it's own a= symetric key pair so it can prove it is the same instance of the GC on subs= equent requests.. The GS MAY return a Dynamic Client a Client Handle for th= e Dynamic Client to identify itself in subsequent requests. A single-page a= pplication with no active server component is an example of a Dynamic Clien= t.
    • 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.<= /a>
    • Interaction=C2=A0- how = the GC directs the User to interact with the GS. This document defines the = interaction modes: "redirect", "indirect", and "us= er_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 Gran= t. The Grant URI MUST start with the GS URI.
    • Access=C2=A0- the access granted by t= he RO to the GC and contains an access token. The GS may invalidate an Acce= ss at any time.
    • = Access URI=C2=A0- the URI that represents the Access the GC was gr= anted 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


    --
    Francis Pouatcha
    Co-Founder and Technical Lead=
    adorsys GmbH & Co. KG
    --0000000000005b50ae05ad09a830-- From nobody Sun Aug 16 23:13:30 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 3D8FA3A09C5 for ; Sun, 16 Aug 2020 23:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 GbE3fB54uxvZ for ; Sun, 16 Aug 2020 23:13:24 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 194F03A09C1 for ; Sun, 16 Aug 2020 23:13:24 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id b16so16553822ioj.4 for ; Sun, 16 Aug 2020 23:13:24 -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=lURbfUGMRldcP/EkDl8xs7QJzHbJymroAXb3OA1tqms=; b=Yv8TuB/WAQTE+y1nOwVqVtXpU6tNWq/T1AHDLo8Ilh4yvzlFoqqVPgw1LHPMDIJGAa WR0TKmOt0KMlbDbLh64LNLOguMFynveBA2XZNyoNdDY2sP0XPVfaHSPjLeNUIu9JWFbt LXb4dfS7xUwBsvRAYO/wjs/n9egQornKkYqpFFE0wT/sEpuDOAt/P5Bd+28r97Nb2Ftq jQtbwcoi/V6FLdD/5U0BHEbudCqQY+U4h5FxLBZfnQi/R3NeqAu+up9PAXswXQMD6JsA Ef3GbVqk1M6DI9Ug39rCA0BFTnrBtsklTMlcOylJsbyGFWY9jmp6LxknkJRiIpDrfPvi /LZA== 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=lURbfUGMRldcP/EkDl8xs7QJzHbJymroAXb3OA1tqms=; b=nseEwTpYv/7ErOzALVqJD755wAVpPetlWnkZiz7jwlIMSNpFXEu6MmLTvxCFqZqNyl 3YwC7iDQKGBiwKIpeZMWyPJeBuzkjB5jCk96eCoue2NLdKZZruKqevEEhPDwVBPkeujg vSzhg90efZjzQ2DbWLezBbFwG1DrR2nFKNowFM82t1QbqlAbH3gQr32iWEdLtUqihQ1E mME5T9ubrLQA9pdqvwVNxziW+sjyL689SY3wJFd1w3KGjcVa91D0mxmLyBz4/1w1lfAq 9K0KtlXSLinjSSo90+x+lZ54I/wDSRtmtqL8v5WepZyio3N8gCTuKkxLMGDH5zyWU7OJ ygMA== X-Gm-Message-State: AOAM531qd+mhxJ4EvrwAfb2QrLVTo7+8E0ytPhEoKL6EBO0dYf8nGJd7 /a/ygZXuro4ONLZpL1GpIBX/grGvwDmDcyCZjHU= X-Google-Smtp-Source: ABdhPJxEPCgbV5IlXysu/rNHDgiTYnV/qnfoDczVHYkE0sLLEFfGj3P8Csrq+vDVeMulCbu9J8A3+Fx3VKaE/khs55Q= X-Received: by 2002:a6b:e70d:: with SMTP id b13mr11231595ioh.141.1597644803175; Sun, 16 Aug 2020 23:13:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 17 Aug 2020 08:13:11 +0200 Message-ID: To: Mark Lizar Cc: Tom Jones , Francis Pouatcha , GNAP Mailing List , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000f87b8705ad0caaca" 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 06:13:28 -0000 --000000000000f87b8705ad0caaca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not necessarily. It is a human when user=3DRO (which is indeed a very commo= n case). But when the 2 roles are handled by different persons, then most often we end up using an automated policy engine. Cheers Fabien Le lun. 17 ao=C3=BBt 2020 =C3=A0 01:59, Mark Lizar a= =C3=A9crit : > - consent is the human management of a permission grant the system manage= s > . +1 for not mixing human and system terms for the same endpoint. > > Get Outlook for iOS > ------------------------------ > *From:* TXAuth on behalf of Tom Jones < > thomasclinganjones@gmail.com> > *Sent:* Sunday, August 16, 2020 7:38:13 PM > *To:* Francis Pouatcha > *Cc:* GNAP Mailing List ; Dick Hardt < > dick.hardt@gmail.com> > *Subject:* Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked > introduction > > i disagree - end user needs to be a human =3D use term like subject or > endpoint if you want a non-human > Peace ..tom > > > On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha 40adorsys.de@dmarc.ietf.org> 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 no= t > about having a human, but a terminating edge of the protocol. An "End Use= r" > 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 matte= r > of obtaining a grant to a resource (many reasons: privacy, confidentialit= y, > abstraction, ...). Generally the GS will need information (claims) about > the "Requesting Party" to proceed with the authorisation decision. In thi= s > 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 fo= r > the resource access. They are generally used by GS (and later RS) as inpu= t > 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 o= n > the mailing list. But we have no mean yet to isolate good inputs for late= r > 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 structu= re > 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. 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 > ] = Section > 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 > > > > -- > 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 > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f87b8705ad0caaca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Dick,

    =
    Thanks for pointing this out. This is th= e new diagram where=C2=A0++++ refers=C2=A0to what Endpoint/Human interactio= n 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 | Reques= ting =C2=A0| =C2=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|
    =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 +--->| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 +-->| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 + =C2=A0|=C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 | =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 = + (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=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 Ser= ver =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 k= now what is part of the protocol:
    Alt-1: only (1..6). This is what you specified in section 1.2, and I am fi= ne with that.
    Alt-2: Alt-1=C2=A0+= =C2=A0(B0, C0). This is a result of the discussion we have been having arou= nd privacy, GS as big brother, aso...

    P.S.: an authentication= [RP]+++(A)+++>[GC] can be assumed, but shall be irrelevant for the prot= ocol. [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 li= ke [GS].

    Best regards.
    /Francis
    On Sun, Aug 16, 20= 20 at 3:46 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
    Hello Dick,=C2=A0my fee= dback below:

    1.2: Exce= llent and Focussed
    -> The word "Grant Client" looks great f= or me.

    1.3:
    Title: Human Interaction -> End User InteractionI would title this "End User" interaction and not "human .= ..". It is not about having a human, but a terminating edge of the pro= tocol. An "End User" can be either human on an IOT device or a ca= r or ...

    Participant: User -> "Requesting Party"
    I w= ill still insist on replacing the word "User" with a role name. M= aybe "Requesting Party" as used by UMA.

    Participant: "= ;Resource Controller". In past discussions there was a consensus on us= ing "Resource Controller" instead.

    (B) I which the GS neve= r 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 "Requ= esting 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 "Aut= horization Server" (AS). The word AS is intentionally chosen here. In = this same login, the path (C0, C1) below will not only return the RC consen= t, but might also return some claims on RC.

    ASs provide authenticati= on "of" and consent collection "from" End Users. End us= ers 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.

    = =C2=A0 =C2=A0 +-------------+ =C2=A0 =C2=A0 =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|
    =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|--(2)-&g= t;| =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 +-------= -----+

    (B0, B1) replace (B). Occur inside step (3), GS asks G= C to collect the claims. GC contacts RP-AS to negotiate those=C2=A0claims. = But it is important to mention that those Claims-RP are not the target Gran= t being negotiated for 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 differe= nce=C2=A0to Bs that occur=C2=A0inside 3). This separation address the Big B= rother 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 migh= t refer to the same "End User".=C2=A0

    Off-topic: The splitting of GS and AS was suggested in s= ome discussions on the mailing list. But we have no mean yet to isolate goo= d 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 int= roduces what I would rather call the trust framework. The purpose of the tr= ust 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" a= nd still make them roles. This is:
    Terminology (Are all roles)
    =C2=A0= -> These roles can be borne by End Users
    =C2=A0 =C2=A0 =C2=A0-> R= equesting Party (RP)
    =C2=A0 =C2=A0 =C2=A0-> Resource Controller (RC)<= br>=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 necessa= ry for a qualified review of section 2++.

    Best regards<= /font>
    /Francis
    Not necessarily. It is a human when user=3DRO (which is i= ndeed a very common case).=C2=A0
    But when the 2 roles are = handled by different persons, then most often we end up using an automated = policy engine.

    Cheers
    Fabien=C2=A0

    Le lun. 17 ao=C3=BBt 2020 =C3=A0 01:= 59, Mark Lizar <mark@openconsent= .com> a =C3=A9crit=C2=A0:
    - consent is the human management of a permiss= ion grant the system manages . =C2=A0=C2=A0+1 for not mixing human and syst= em terms for the same endpoint. =C2=A0

    From:= TXAuth <txauth-bounces@ietf.org> on behalf of Tom Jones <= ;thomasclinganjones@gmail.com>
    Sent: Sunday, August 16, 2020 7:38:13 PM
    To: Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org<= /a>>
    Cc: GNAP Mailing List <    txauth@ietf.org>; Dick Hardt <di= ck.hardt@gmail.com>
    Subject: Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked = introduction
    =C2=A0
    i disagree - end user needs to be a human =3D use term lik= e subject or endpoint if you want a non-human
    Peace ..tom


    On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <fpo= =3D40adorsys.de@dmarc.ietf.org> wrote:
    Hello Dick,=C2=A0my 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 pro= tocol. An "End User" can be either human on an IOT device or a ca= r 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, confid= entiality, abstraction, ...). Generally the GS will need information (claim= s) 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 mi= ght 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 addre= ss some privacy concerns 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=A0Reso= urce =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 Se= rver =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|<= 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|--------------(5)-------------&= gt;| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =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 claims. GC contacts RP-AS to negotiate those=C2= =A0claims. But it is important to mention that those Claims-RP are not the = target Grant being negotiated for the resource access. They are generally=C2=A0used by GS (and later RS) as input into pe= rforming authz decisions.

    (C0, C1) replace (C). They occur=C2=A0after s= tep (3) (Beware of the difference=C2=A0to Bs that occur=C2=A0inside 3). Thi= s separation address the Big Brother problem we have been discussing in the= list.

    Essential is to mention that in an instantiat= ion of this model for oAuth for example:
    - GS, RP-AS and RC-AS might be the same entit= y.
    - RP and RC might refer to the same "End= User".=C2=A0

    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 pa= ges (like use cases).

    1.4:
    The Trust model introduces what I would rather call the trust framework. Th= e purpose of the trust framework will be to address topics mentioned in thi= s section. There is still a lot of discussion needed to have a structure fo= r this section.


    1.5
    I suggest again we replace Human with "End User" and still make t= hem roles. This is:
    Terminology (Are all roles)
    =C2=A0 -> These roles can be borne by End Users
    =C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)
    =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 necessa= ry for a qualified review of section 2++.

    Best regards
    /Francis

    On Sat, Aug 15, 2020 at 7:03 PM Dick Hardt <dick.hard= t@gmail.com> wrote:
    Hello

    I just pushed an updated version of XAuth:


    Highlights:
    • renamed Client -> Grant Client
    • Introduced Client Owner, Gran= t Server Owner as new entities
    • renamed=C2=A0Authorizations -> Ac= cess
    • An Access contains=C2=A0an array of RAR objects now
    • Re= worked 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 Protoc= ol (GNAP). The protocol supports the widely deployed use cases supported by= OAuth 2.0=C2=A0[RFC6749]=C2=A0&a= mp;=C2=A0[RFC6750], OpenID Connect=C2=A0[OIDC]=C2=A0- a= n extension of OAuth 2.0, as well as other extensions. Related documents include: GNAP - Advanced Features=C2=A0[GNAP_Advanced]=C2=A0and JOSE Authentication=C2=A0[JOSE_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 d= irectly support asymetric cryptographic functions. Standards have emerged f= or signing and encrypting tokens with rich payloads (JOSE) that are widely deployed.

    GNAP simplifies the overall architectural model, takes advantage of today&#= 39;s technology landscape, provides support for all the widely deployed use= cases, offers numerous extension points, and addresses many of the securit= y 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 minimi= ze 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 Gr= ant 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 identit= y claims, and the requested resource access. Extensions may define addition= al 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=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 t= o the GC. This step is not in scope for this document.

    1.3.=C2=A0Human Interactions

    The Grant Client may be interacting with a human end-user (User), and the G= rant Client may need to get authorization to release the Grant from the Use= r, 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. 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 ac= cess 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<= /a>

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

    <= /p>

    1.4..=C2=A0Trust Model

    In addition to the User and the Resource Owner, there are three other entit= ies that are part of the trust model:<= /p>

    • Client Owner=C2=A0(CO) - the legal entity that owns the Gr= ant 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 i= dentity 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 th= e 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 t= he CO

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

    (C) CO trusts claims issued by the GSO=

    =

    (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<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.5-2.2.2.1" style=3D"text-decoration-line:none;color:rgb(102,102,102)"= target=3D"_blank" rel=3D"noreferrer">
      • 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 G= C
      • 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 documentat= ion 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 Serve= r.
      • 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 in= dependently.

    Reused Terms

    • access token=C2=A0- an access 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 Claim 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 C= lient 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= [RFC7519]=C2=A0Section 2.
    • authN=C2=A0- short for authentication.
    • authZ=C2=A0- short for authorization.

    • GS URI=C2=A0- the endpoint at the GS the GC calls to creat= e 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 ke= y that is linked to the Client ID. The GS may have different policies for w= hat 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 re= gistered with the GS, and each instance will generate it's own asymetri= c 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 re= quests. A single-page application with no active server component is an exa= mple of a Dynamic Client.
    • Client Handle=C2=A0- a unique identifier at the GS for a D= ynamic Client for the Dynamic Client to refer to itself in subsequent reque= sts.
    • Interaction=C2=A0- how the GC directs the User to interact= with the GS. This document defines the interaction modes: "redirect&q= uot;, "indirect", and "user_code" in=C2=A0Section 5.
    • Grant=C2=A0- the user identity claims and/or resource acce= ss the GS has granted to the Client. The GS MAY invalidate a Grant at any t= ime.
    • Grant URI=C2=A0- the URI that represents the Grant. The Gr= ant URI MUST start with the GS URI.<= /li>
    • Access=C2=A0- the access granted by the RO to the GC and c= ontains an access token. The GS may invalidate an Access at any time.
    • Access URI=C2=A0- the URI that represents the Access the G= C was granted by the RO. The Access URI MUST start with the GS URI.. The Ac= cess URI is used to refresh an access token.


    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>


    --
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --000000000000f87b8705ad0caaca-- From nobody Mon Aug 17 00:38:12 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 98EA43A052C for ; Mon, 17 Aug 2020 00:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 h_dswjSzR8IG for ; Mon, 17 Aug 2020 00:38:07 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 2A1A13A13D8 for ; Mon, 17 Aug 2020 00:38:07 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id p18so9861817ilm.7 for ; Mon, 17 Aug 2020 00:38:07 -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=JT+YA4zYXK7ET6guC4l4nlecohH2UUWF1P/hWepzIf4=; b=Rkl6Yq/R2gpLKxwiBGWsciwi9BcFZqxRq7ZF/0A29OUHcq5XzR2EsPJy65XeZww318 NH+NK2i0ZbkTxn/fC5aW1mQOL1oJP7WR0AK28KDBcX/LPoGLGXju3st2ssUmhIzpkDHc nbBkkiuSdXBcSsejG59EJ+dfgp4oQk+kIazFfD4kD6ylBVAWh0lPsl93M9Dnb42aqr79 eZAF3L8TeOuzZIUnK4oi6TvDPOm2QNnD7XnTxCRpZWTWTj3aVAsvuUxcNNha79+pgNa5 A/9tqfra7SrV/MCDq29OJfDbiQUJRi4fk5HhLjACZCOJdjvyvze6TJ9H67Yu0+8j6Fb4 BdAQ== 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=JT+YA4zYXK7ET6guC4l4nlecohH2UUWF1P/hWepzIf4=; b=i+Gs1o59XojHtvXNnhfsAqUHuqY4bspnjTO9Jfjcs9yFPHMyxWeVAeTmhI2j+SjNvU 3C8QcgNDbgisfe9vFu+nRI3Wc5URb/woh1A1NB7IoGDm0htD0fQ3ZpBpezxU7BEBoQcw UQnqYUGo3YX/vEFOnk7uLnzSlDfXN+hItzDc03lNE92nd2wu9h7sVnLToBlAb6DoeCTy PTUfMswZqhz9Y8GcwNPGmGqAMpX/jwLKmXBnWCnzWsb/dbFjeIh9WAorcuGDcJIyl1Gl IflWRsAP3dsa2vzvc6M+FFdS9YPhnS61SGAYmWb92i4EtZW+9fwFzzKuc01XAA9hWCSR nwUQ== X-Gm-Message-State: AOAM533F4J6kGZN09AomxZGEVp5K9L0Y3cDAd7aXGJfCRDoNmV1SuffE 31X2COUh5Wr/ow6Wu6j/jg3xfuipeRaTbSGxxJk= X-Google-Smtp-Source: ABdhPJzXeH/W6zV1SbqvuAfUmgngHMlrLzQxes4wBqjPhN9OMeQ9Knxjo7pysovW5TlEXcGNC/p5PvUNea5B5wzY1nM= X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr11715714ils.188.1597649886260; Mon, 17 Aug 2020 00:38:06 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 17 Aug 2020 09:37:54 +0200 Message-ID: To: Dick Hardt Cc: Justin Richer , Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f237e805ad0dd9da" Archived-At: Subject: Re: [GNAP] Terminology 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 07:38:12 -0000 --000000000000f237e805ad0dd9da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Dick. Assertions about the Grant Client could be cool ;-) I think it's great that you list the terms you use in the spec, in section 1.5. Fabien On Sun, Aug 16, 2020 at 10:39 PM Dick Hardt wrote: > Sorry Fabien, I had started this email and had not sent it. > > If we are successful, other ISO may build extensions on GNAP, just as > OpenId Connect was built on top. Hopefully we will have created the right > extension points so that it is straightforward. Here are some examples of > other things that could be granted (I don't expect these to be worked on = in > this WG, or at least not anytime soon): > > - A grant of "digital money" from the Grant Server to the Grant Client. > The GS is granting the funds to the GC with the User's authorization. Thi= s > is not the same as authorizing a payment per the example in the wiki. > > - An assertion about the Grant Client made by the Grant Server, > potentially with the User's authorization. This assertion could allow the > GC to prove something about itself to a separate entity, or even a separa= te > GS. > > /Dick > > > On Wed, Aug 12, 2020 at 9:43 AM Fabien Imbault > wrote: > >> Hi Dick, >> >> Maybe to make that discussion more concrete, what else do you imagine >> could be exchanged (beyond resource & idclaims)? A few examples? >> >> Cheers >> Fabien >> >> >> >> On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt wrote: >> >>> What is being granted is whatever is being negotiated between the Grant >>> Server and the Grant Client -> Which fits into the name of the WG, Gran= t >>> Negotiation and Authorization Protocol, allows us to have names that ar= e >>> specific and precise for the roles (Grant Server and Grant Client rathe= r >>> than Requesting Party), and is usable by an extension that wants to >>> negotiate some new thing between the two roles. >>> >>> I introduced the term "Grant" in XAuth to mean what the client >>> requested, and what the "server" provided, which included both resource >>> access and identity claims. You are narrowly defining grant to ONLY mea= n >>> "access to something". Sometimes I think you just want to disagree with= me. >>> :) >>> >>> I'd be interested in hearing from others! >>> >>> >>> >>> In the current drafts, that is resource access and identity claims. >>> >>> =E1=90=A7 >>> >>> On Wed, Aug 12, 2020 at 8:58 AM Justin Richer wrote: >>> >>>> What is being granted is access to something. This makes sense in term= s >>>> of rights bound to an access token, but I would argue it makes less se= nse >>>> for things returned directly. >>>> >>>> Since you and I also disagree on whether returning things directly is >>>> an important distinction (even though both the XAuth and XYZ proposals= make >>>> this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d w= ant to extend the >>>> notion of =E2=80=9Cgrant=E2=80=9D to include anything and everything i= n the request and >>>> response. >>>> >>>> I am arguing for it being more specific and precise. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 11, 2020, at 6:08 PM, Dick Hardt wrote: >>>> >>>> A grant is whatever the client is asking from the server. Currently we >>>> have access to resources and identity claims. It could contain anythin= g >>>> else an extension adds that a client may request from a server. >>>> >>>> Given the definition of grant that I included, why is grant not the >>>> right term to use for this? >>>> >>>> >>>> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer wrote: >>>> >>>>> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I sai= d that your >>>>> definition of it was problematic. Namely, the desire to lump in claim= s >>>>> about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: >>>>> >>>>> I agree that orchestrator may be a role in the protocol -- it is not = a >>>>> role in XYZ or XAuth today. >>>>> >>>>> Justin: would you explain why you think the term "grant" is >>>>> problematic? It is in the WG name! >>>>> >>>>> The client is receiving more than access to resources from the GS, it >>>>> is also receiving claims, so "client of the resource" is too limiting= . >>>>> >>>>> Reading the definition of grant[1], it fits as a verb of what the GS >>>>> is doing, and fits as a noun of what the GS provides to the client. >>>>> >>>>> A Grant Server is an Authorization Server in OAuth, and an OpenID >>>>> Provider in OpenID Connect. >>>>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID >>>>> Connect. >>>>> >>>>> Having new terms (GS and GC) in GNAP, separating the roles from OAuth >>>>> and OpenID Connect. >>>>> It is straightforward to know what a GC and GS do when you understand >>>>> that a grant is a combination of resource access (from OAuth) and cla= ims >>>>> (from OpenID Connect). >>>>> >>>>> /Dick >>>>> >>>>> [1] https://www.dictionary.com/browse/grant >>>>> verb (used with object) >>>>> to bestow or confer, especially by a formal act:to grant a charter. >>>>> to give or accord:to grant permission. >>>>> to agree or accede to:to grant a request. >>>>> to admit or concede; accept for the sake of argument:I grant that >>>>> point. >>>>> SEE MORE >>>>> noun >>>>> something granted, as a privilege or right, a sum of money, or a trac= t >>>>> of land:Several major foundations made large grants to fund the >>>>> research project. >>>>> the act of granting. >>>>> >>>>> >>>>> [1] >>>>> >>>>> >>>>> >>>>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer >>>>> wrote: >>>>> >>>>>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what t= he classical >>>>>> =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term = =E2=80=9Corchestrator=E2=80=9D fits with the >>>>>> =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been brought up = here before, so I=E2=80=99m inclined to >>>>>> believe it can be a separate role from the client. >>>>>> >>>>>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing = as it is not a >>>>>> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient o= f the resource=E2=80=9D. >>>>>> >>>>>> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D >>>>>> and that=E2=80=99s just going to muddle everything. >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote= : >>>>>> >>>>>> I echo Mike's comments on preserving names when possible. The shift >>>>>> from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to m= any. >>>>>> >>>>>> I also echo Tom's comments about separating Entities from Roles. >>>>>> >>>>>> Orchestration[1] in my opinion is not what the "client" is doing. >>>>>> >>>>>> Below is a stab at separating the entities and the roles >>>>>> >>>>>> /Dick >>>>>> >>>>>> *Tl;dr: * >>>>>> - Client -> Grant Client >>>>>> - added Relying Party, Claims Issuer, and Grant Server Operator as >>>>>> entities >>>>>> >>>>>> *Roles* - parties to the protocol >>>>>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>>>> >>>>>> *Entities* - parties to a Trust Framework >>>>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server >>>>>> Operator (GSO), Resource Owner (RO) >>>>>> >>>>>> *Grant *- may contain claims and/or access to resources >>>>>> >>>>>> *#Protocol Roles* >>>>>> >>>>>> *Grant Client* (GC) >>>>>> - used by User >>>>>> - operated / provided by RP >>>>>> - requests Grants from the GS >>>>>> - access resources at an RS >>>>>> - consumes Claims >>>>>> >>>>>> *Grant Server* (GS) >>>>>> - operated by GSO >>>>>> - may interact with the User >>>>>> - may interact with the RO >>>>>> - accepts grant requests from GCs >>>>>> - issues grants to GCs >>>>>> - may issue claims >>>>>> >>>>>> *Resource Server* (RS) >>>>>> - manages access to resources for the RO >>>>>> - provides access to resources for the GC >>>>>> - accepts access granted by the GS >>>>>> >>>>>> *#Legal Entities* >>>>>> >>>>>> *User* >>>>>> - uses Grant Client >>>>>> - may interact with the Grant Server >>>>>> - may also be a RO >>>>>> - trusts RP, Issuer, GSO >>>>>> >>>>>> *Relying Party* (RP) >>>>>> - provides Grant Client to the User. >>>>>> - may trust Issuers, GSOs, and ROs >>>>>> >>>>>> *Claims Issuer* (Issuer) >>>>>> - issues claims to RP >>>>>> - may use GS or RS to issue claims >>>>>> >>>>>> *Grant Server Operator* (GSO) >>>>>> - operates the GS >>>>>> - trusted by User, RP, and RO >>>>>> - may also be an Issuer >>>>>> >>>>>> *Resource Owne*r (RO) >>>>>> - owns resources at the RS >>>>>> - trusts GSO to control access to the resources >>>>>> - may be same entity as the User >>>>>> - may also be an Issuer >>>>>> >>>>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >>>>>> >>>>>> Orchestration (computing) >>>>>> From Wikipedia, the free encyclopedia >>>>>> Jump to navigation >>>>>> Jum= p >>>>>> to search >>>>>> >>>>>> In system administration >>>>>> , >>>>>> *orchestration* is the automated configuration >>>>>> , >>>>>> coordination, and management of computer systems and software >>>>>> .[1] >>>>>> >>>>>> A number of tools exist >>>>>> for >>>>>> automation of server configuration and management, including Ansible >>>>>> , Puppet >>>>>> , Salt >>>>>> , Terraform >>>>>> ,[2] >>>>>> >>>>>> and AWS CloudFormation >>>>>> .[3] >>>>>> >>>>>> Usage[edit >>>>>> >>>>>> ] >>>>>> Orchestration is often discussed in the context of service-oriented >>>>>> architecture >>>>>> , >>>>>> virtualization >>>>>> , provisionin= g >>>>>> , converged >>>>>> infrastructure >>>>>> and dynamic >>>>>> datacenter topics. >>>>>> Orchestration in this sense is about aligning the business request w= ith the >>>>>> applications, data, and infrastructure.[4] >>>>>> >>>>>> In the context of cloud computing >>>>>> , the main difference >>>>>> between workflow automation >>>>>> and >>>>>> orchestration is that workflows are processed and completed as proce= sses >>>>>> within a single domain for automation purposes, whereas orchestratio= n >>>>>> includes a workflow and provides a directed action towards larger go= als and >>>>>> objectives.[1] >>>>>> >>>>>> In this context, and with the overall aim to achieve specific goals >>>>>> and objectives (described through quality of service >>>>>> parameters), for >>>>>> example, meet application performance goals using minimized cost[5] >>>>>> and >>>>>> maximize application performance within budget constraints.[6] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote: >>>>>> >>>>>>> One of the things that people hated about OAuth was it invented new >>>>>>> terminology that wasn=E2=80=99t in common use. But for better or f= or worse, the >>>>>>> terms Client, Authorization Server, and Protected Resource are now = widely >>>>>>> understood. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even= more >>>>>>> novel terms, when existing terms will fit the bill. Client wasn=E2= =80=99t a >>>>>>> perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the voc= abulary menagerie would >>>>>>> definitely make things worse. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* TXAuth *On Behalf Of *Tom Jones >>>>>>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>>>>>> *To:* Dave Tonge >>>>>>> *Cc:* Francis Pouatcha ; Justin Richer < >>>>>>> jricher@mit.edu>; Dick Hardt ; Benjamin Kaduk >>>>>>> ; Fabien Imbault ; Denis < >>>>>>> denis.ietf@free.fr>; txauth@ietf.org >>>>>>> *Subject:* Re: [GNAP] Terminology >>>>>>> >>>>>>> >>>>>>> >>>>>>> the term "orchestator" does not match any use case i have. >>>>>>> >>>>>>> Let's be clear that there are four entities to a single transaction >>>>>>> in the real world sense of things. (and others that support the >>>>>>> transaction.) >>>>>>> >>>>>>> Then we can focus on the end point roles. I will focus on the data >>>>>>> privacy issues, API's have the same parties with different terminol= ogy. >>>>>>> >>>>>>> 1. the subject of the data to be transferred. >>>>>>> >>>>>>> 2. the user of a grant from the subject to act as delegate. (see >>>>>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable >>>>>>> the user) >>>>>>> >>>>>>> 3. the site that has a repository of user data with legal >>>>>>> obligations to protect that data (the GDPR) (role resource server.) >>>>>>> >>>>>>> 4 the site that wants either access to the data, or some privacy >>>>>>> preserving statement about the existence and content of the data. (= role of >>>>>>> client, vendor, PISP, etc.) >>>>>>> >>>>>>> 5. some sorts of facilitator sites for allowing access (roles like >>>>>>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have b= een left >>>>>>> out of OAUTH for good reason. >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is a note supporting the separation of roles from legal >>>>>>> entities. BTW, I firmly believe that the legal entity also needs t= o be >>>>>>> ID'd by the transaction. >>>>>>> >>>>>>> Peace ..tom >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>>>>>> wrote: >>>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree that "client" can be confusing. I would be in support of >>>>>>> alternative terminology. >>>>>>> >>>>>>> We can always have some wording that explains that an "Orchestrator= " >>>>>>> in GNAP plays a similar role to "Client" in OAuth. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>> Hi Francis, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I like your proposal, seems much more intuitive. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>>>>>> =C3=A9crit : >>>>>>> >>>>>>> Hello Denis, Justin, Dick, Fabien, >>>>>>> >>>>>>> >>>>>>> >>>>>>> In this post ( >>>>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-= JOGNw/) >>>>>>> i suggested we use the word "Orchestrator" to designate the piece o= f >>>>>>> software that orchestrate interaction between "Requestor" (a.k.a. U= ser), AS >>>>>>> and RS to obtain the protected resource. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are turning around the same topic. As soon as we go beyond the >>>>>>> original oAuth protocol, the word 'Client' becomes confusing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In the same response, I suggest we talk about "roles" and not >>>>>>> "entities". >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best regards. >>>>>>> >>>>>>> /Francis >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>> I still think that client was the right name in OAuth 2, as the >>>>>>> client wanted to do a client-server interaction, so the client used= OAuth 2 >>>>>>> to get an access token to interact with the "server". >>>>>>> >>>>>>> >>>>>>> >>>>>>> I do agree that it is not the best term in GNAP. Primarily because >>>>>>> GNAP is a combination of the client from OAuth 2, and the relying p= arty >>>>>>> from OIDC. >>>>>>> >>>>>>> >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> The term client in OAuth came from the computer science definition >>>>>>> of client-server interaction. >>>>>>> >>>>>>> >>>>>>> >>>>>>> This, I would argue, is exactly why it=E2=80=99s a bad label for so= mething >>>>>>> that=E2=80=99s distinctly more specific in this context, and I woul= d love to see >>>>>>> GNAP adopt a more specific label for the role that we traditionally= called >>>>>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>>>>> >>>>>>> >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The client is getting an access token so it can call a server, >>>>>>> specifically, a resource server (to differentiate it from the autho= rization >>>>>>> server). >>>>>>> >>>>>>> >>>>>>> >>>>>>> The confusion in my experience usually stems from people >>>>>>> working with software that is acting in multiple roles. IE, the >>>>>>> software that is acting as a client in once context, is also acting= as an >>>>>>> RS in other contexts, or even acting as an AS. The other confusion = is that >>>>>>> people view clients as being the software the user is using -- alth= ough it >>>>>>> may not be acting as a client in the oauth context. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> To me, client has always been a strange word in the context of >>>>>>> OAuth, as it has a meaning well defined both in everyday life (this= client >>>>>>> is a good customer) and in computer science (client-server interact= ion). >>>>>>> Thus I always have to make the mental translation to the OAuth worl= d before >>>>>>> any discussion... And any teaching experience shows that it does ma= ke the >>>>>>> concepts hard to grasp for a majority of (clever) people. >>>>>>> >>>>>>> >>>>>>> >>>>>>> As for the RO, previous discussions suggested Resource >>>>>>> Controller (RC) also, which may be a bit more specific than manager= . >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>>>>> >>>>>>> Justin and Dick, >>>>>>> >>>>>>> >>>>>>> >>>>>>> [Was: "Revisiting the photo sharing example (a driving use case fo= r >>>>>>> the creation of OAuth)"] >>>>>>> >>>>>>> >>>>>>> >>>>>>> So let us attempt to define new terms: >>>>>>> >>>>>>> *initiating application (IA)*: application by means of which a user >>>>>>> initiates interactions with RS(s) and AS(s) >>>>>>> >>>>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>>>> which is currently defined as: >>>>>>> >>>>>>> Resource Owner (RO): entity capable of granting access to a >>>>>>> protected resource >>>>>>> >>>>>>> I propose to replace it with Resource Manager (RM): >>>>>>> >>>>>>> *Resource Manager (RM)* : application or user that manages an >>>>>>> access decision function of a Resource Server >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree with Justin. Redefining well used terms will lead to >>>>>>> significant confusion. If we have a different role than what we hav= e had >>>>>>> in the past, then that role should have a name not being used alrea= dy in >>>>>>> OAuth or OIDC. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Given what we have learned, and my own experience explaining what a >>>>>>> Client is, and is not, improving the definition for Client could pr= ove >>>>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For example, clarifying that a Client is a role an entity plays in >>>>>>> the protocol, and that the same entity may play other roles at othe= r times, >>>>>>> or some other language to help differentiate between "role" and "en= tity". >>>>>>> >>>>>>> >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a = better fit, but >>>>>>> I=E2=80=99m not really in favor of taking an existing term and appl= ying a >>>>>>> completely new definition to it. In other words, I would sooner sto= p using >>>>>>> =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and = accurate term for the >>>>>>> role than to define =E2=80=9Cclient=E2=80=9D as meaning something c= ompletely different. We >>>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the >>>>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient= =E2=80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cse= rver=E2=80=9D on its own but instead >>>>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and= =E2=80=9CResource Server=E2=80=9D. >>>>>>> >>>>>>> >>>>>>> >>>>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do >>>>>>> is ignore the fact that GNAP is going to be coming up in a world th= at is >>>>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t= have a blank >>>>>>> slate to work with, but neither are we bound to use the same terms = and >>>>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>>>> >>>>>>> >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think that is fundamentally part of the question: >>>>>>> >>>>>>> We are clear that we are producing a protocol that is >>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>> reusing terms >>>>>>> from OAuth 2.0 but with different definitions may lead to unnecessa= ry >>>>>>> confusion >>>>>>> >>>>>>> >>>>>>> >>>>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>>>> should not change the meanings of any definition. If we are saying = this >>>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick = the best >>>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I = have a >>>>>>> lot of first hand experience of industries "ruining words", and att= empting >>>>>>> to side-step the problem rather than redefining the word just confu= ses >>>>>>> everyone as everyone forgets the original meaning as new documents = come >>>>>>> out, but the confusion with the use of a non-obvious word continues= . >>>>>>> >>>>>>> >>>>>>> >>>>>>> Food for thought. >>>>>>> >>>>>>> - Warren >>>>>>> >>>>>>> >>>>>>> *Warren Parad* >>>>>>> >>>>>>> Founder, CTO >>>>>>> >>>>>>> Secure your user data and complete your authorization architecture. >>>>>>> Implement Authress . >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote= : >>>>>>> >>>>>>> Hi Denis, >>>>>>> >>>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>>> > Hi Justin, >>>>>>> > >>>>>>> > Since you replied in parallel, I will make a response similar to >>>>>>> the one >>>>>>> > I sent to Dick. >>>>>>> > >>>>>>> > > Hi Denis, >>>>>>> > > >>>>>>> > > I think there=E2=80=99s still a problem with the terminology in= use >>>>>>> here. What >>>>>>> > > you describe as RS2, which might in fact be an RS unto itself, >>>>>>> is a >>>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a cli= ent of RS1/. What >>>>>>> you >>>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth wo= rld, but it is >>>>>>> not at >>>>>>> > > all the same as an OAuth client. I appreciate your mapping of >>>>>>> the >>>>>>> > > entities below, but it makes it difficult to hold a discussion >>>>>>> if we >>>>>>> > > aren=E2=80=99t using the same terms. >>>>>>> > > >>>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG= we can >>>>>>> define >>>>>>> > > our own terms. The bad news is that this is really hard to do. >>>>>>> > > >>>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with n= ew >>>>>>> definitions, >>>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we d= efine >>>>>>> things. >>>>>>> > >>>>>>> > In the ISO context, each document must define its own terminology= . >>>>>>> The >>>>>>> > boiler plate for RFCs does not mandate a terminology or >>>>>>> definitions section >>>>>>> > but does not prevent it either. The vocabulary is limited and as >>>>>>> long as >>>>>>> > we clearly define what our terms are meaning, we can re-use a ter= m >>>>>>> already >>>>>>> > used in another RFC. This is also the ISO approach. >>>>>>> >>>>>>> Just because we can do something does not necessarily mean that it >>>>>>> is a >>>>>>> good idea to do so. We are clear that we are producing a protocol >>>>>>> that is >>>>>>> conceptually (if not more strongly) related to OAuth 2.0, and >>>>>>> reusing terms >>>>>>> from OAuth 2.0 but with different definitions may lead to unnecessa= ry >>>>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>>>> Dick to >>>>>>> use the term "GS" in XAuth, picking a name that was not already use= d >>>>>>> in >>>>>>> OAuth 2.0. >>>>>>> >>>>>>> -Ben >>>>>>> >>>>>>> -- >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> -- >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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/ >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>> Technology Limited which is authorised and regulated by the Financi= al >>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the >>>>>>> Financial Services Register (FRN 809360) at https://register.fca.or= g.uk/ >>>>>>> . Moneyhub Financial Technology is re= gistered >>>>>>> in England & Wales, company registration number 06909772. Moneyhub >>>>>>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus= Building, >>>>>>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>>>>>> >>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>> copyright, and the information in it is confidential. Use of this e= mail or >>>>>>> of any information in it other than by the addressee is unauthorise= d and >>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any att= achments >>>>>>> are virus-free, it is the recipient's sole responsibility to scan a= ll >>>>>>> attachments for viruses. All calls and emails to and from this comp= any may >>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>> company's business. Any opinions expressed in this email (or in any >>>>>>> attachments) are those of the author and do not necessarily represe= nt the >>>>>>> opinions of Moneyhub Financial Technology Limited or of any other g= roup >>>>>>> company. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>> >>>>> >>>> --000000000000f237e805ad0dd9da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Dick. Assertions about the Grant Client could be co= ol ;-)

    I think it's great that you list the terms yo= u use in the spec, in section 1.5.=C2=A0=C2=A0

    Fab= ien

    On Sun, Aug 16, 2020 at 10:39 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    Sorry Fabien, I had started this email and had not sent it.

    =
    If we are successful, other ISO may build extensions on GNAP, just as = OpenId Connect was built on top. Hopefully we will have created the right e= xtension points so that it is straightforward. Here are some examples of ot= her things that could be granted (I don't expect these to be worked on = in this WG, or at least not anytime soon):

    - = A grant of "digital money" from the Grant Server to the Grant Cli= ent. The GS is granting the funds to the GC with the User's authorizati= on. This is not the same as authorizing a payment per the example in the wi= ki.

    - An assertion about the Grant Client ma= de by the Grant Server, potentially with the User's authorization. This= assertion could allow the GC to prove something about itself to a separate= entity, or even a separate GS.

    /Dick

    On Wed, Aug 12, 2020 at 9:43 AM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
    Hi Dick,=C2=A0

    Maybe to make that discussion= more concrete, what else do you imagine could be exchanged (beyond resourc= e & idclaims)? A few examples?

    Cheers
    Fabien=C2=A0



    On Wed, Aug 12, 2020 at 6= :40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    What is being granted is whatever= is being negotiated between the Grant Server and the Grant Client -> Wh= ich fits into the name of the WG, Grant Negotiation and Authorization Proto= col, allows us to have names that are specific and precise for the roles (G= rant Server and Grant Client rather than Requesting Party), and is usable b= y an extension that wants to negotiate some new thing between the two roles= .=C2=A0

    I introduced the term "Grant" in XAuth= to mean what the client requested, and what the "server" provide= d, which included both resource access and identity claims. You are narrowl= y defining grant to ONLY mean "access to something". Sometimes I = think you just want to disagree with me. :)

    I'= d be interested in hearing from others!



    In the current drafts, that is resource= access and identity claims.=C2=A0

    3D""=E1=90=A7

    On Wed, Aug 12, 2020 at 8:58 AM Justin Richer <jricher@mit.edu> = wrote:
    What= is being granted is access to something. This makes sense in terms of righ= ts bound to an access token, but I would argue it makes less sense for thin= gs returned directly.

    Since you and I also disagree on w= hether returning things directly is an important distinction (even though b= oth the XAuth and XYZ proposals make this distinction), it doesn=E2=80=99t = surprise me that you=E2=80=99d want to extend the notion of =E2=80=9Cgrant= =E2=80=9D to include anything and everything in the request and response.= =C2=A0

    I am arguing for it being more specific and= precise.

    =C2=A0=E2=80=94 Justin

    On Aug 11, 2020, at 6:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    A grant is whatever the client= is asking from the server. Currently we have access to resources and ident= ity claims. It could contain anything else an extension adds that a client = may request from a server.

    Given the definition of grant= that I included, why is grant not the right term to use for this?


    On Tue, Aug 11, 2020 at 1:35 PM Justin Richer <jricher@mit.edu> wrote:
    <= /div>
    I did not say t= he term =E2=80=9Cgrant=E2=80=9D was problematic, I said that your definitio= n of it was problematic. Namely, the desire to lump in claims about the use= r into the definition of the =E2=80=9Cgrant=E2=80=9D.=C2=A0

    <= div>=C2=A0=E2=80=94 Justin

    On Au= g 11, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    I agree that orchestrator may be a role in the protocol -- it= is not a role in XYZ or XAuth today.

    Justin: would you = explain why you think the term "grant" is problematic? It is in t= he WG name!

    The client is receiving=C2=A0more than= access to resources from the GS, it is also receiving=C2=A0claims, so &quo= t;client of the resource" is too limiting.

    Re= ading the definition of grant[1], it fits as a verb of what the GS is doing= , and fits as a noun of what the GS provides to the client.

    <= /div>
    A Grant Server is an Authorization Server in OAuth, and an OpenID= Provider in OpenID Connect.
    The Grant Client is a Client in OAut= h, and a Relying Party in OpenID Connect.

    Having n= ew terms (GS and GC) in GNAP, separating the roles from OAuth and OpenID Co= nnect.
    It is straightforward=C2=A0to know what a GC and GS do whe= n you understand that=C2=A0a grant is a combination of resource access (fro= m OAuth) and claims (from OpenID Connect).

    /Dick

    verb (used= with object)

    to bestow or confer, especially by a formal act:to grant a charter.
    to give or= accord:to grant permission.
    to agree or accede to:to grant a request.
    to admit or concede; accept for the sake of argument:I grant that point.

    noun

    something granted, = as a privilege or right, a sum of money, or a tract of land:Several major foundations made large grants to fund the rese= arch project.
    the act of granting.


    [1]=C2=A0



    On Tue, Aug 11, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrot= e:
    I agree = that =E2=80=9Corchestration=E2=80=9D is separate from what the classical = =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2=80=9C= orchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D concept th= at=E2=80=99s been brought up here before, so I=E2=80=99m inclined to believ= e it can be a separate role from the client.

    I personall= y think that =E2=80=9Cgrant client=E2=80=9D is confusing as it is not a =E2= =80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of the reso= urce=E2=80=9D.

    I also think it=E2=80=99s problemat= ic to lump in user claims with a =E2=80=9Cgrant=E2=80=9D and that=E2=80=99s= just going to muddle everything.=C2=A0

    =C2=A0=E2= =80=94 Justin

    On Aug 11, 2020, a= t 3:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    I echo Mike's comment= s on preserving names when possible. The shift from "consumer" in= OAuth 1 to "client" in OAuth 2 was confusing to many.
    <= div>
    I also echo Tom's comments about separating Entities= from Roles.

    Orchestration[1] in my opinion is not= what the "client" is doing.

    Below is a = stab at separating the entities and the roles

    /Dic= k

    Tl;dr:=C2=A0
    - Client=C2=A0->= ; Grant Client
    - added Relying Party, Claims Issuer, and Grant Se= rver Operator as entities

    Roles - part= ies to the protocol
    Grant Client (GC), Grant Server (GS), Resourc= e Server (RS)

    Entities - p= arties to a Trust Framework
    User, Relying Party (RP), Claims Issuer (Is= suer), Grant Server Operator (GSO), Resource=C2=A0Owner (RO)

    Grant -=C2=A0may contain claims and/or a= ccess to resources

    #Protocol Roles

    Grant Client (GC)
    - used by User
    - operated / provided by RP
    - requests Grants from the GS
    =
    - access resources at an RS
    - consumes Claims

    =
    Grant Server (GS)
    - operated by GSO
    -= may interact with the User=C2=A0
    - may interact with the RO
    - accepts grant requests from GCs
    - issues grants to GCs
    - may issue claims

    Resource Server= (RS)
    - manages access to resources for the RO
    - provid= es access to resources for the GC
    - accepts access granted by the= GS

    #Legal Entities

    User
    - uses Grant Client
    - may interact with t= he Grant Server
    - may also be a RO
    - trusts RP, Issuer,= GSO

    Relying Party (RP)
    - provide= s Grant Client to the User.
    - may trust Issuers, GSOs, and ROs

    Claims Issuer (Issuer)
    - issues cl= aims to RP
    - may use GS or RS to issue claims

    Grant Server Operator (GSO)
    - operates the GS
    <= div>- trusted by User, RP, and RO
    - may also be an Issuer

    Resource Owner (RO)
    - owns resour= ces at the RS
    - trusts GSO to control access to the resources
    - may be same entity as the User
    - may also be an Iss= uer


    Orchestration (computing)
    From Wikipedia, the free encyclopedia
    Jump = to navigationJump to search
    In=C2=A0system administration,=C2=A0orchestration=C2=A0is the aut= omated=C2=A0configuration, co= ordination, and management of computer systems and=C2=A0software.[1]
    A=C2=A0number = of tools exist=C2=A0for automation of server configuration and manageme= nt, including=C2=A0Ansible,=C2=A0Puppet,=C2=A0Salt,=C2= =A0Terraform,[2]=C2=A0and=C2=A0AWS CloudFormation.[3]

    Usage[edit]

    Orchestration is of= ten discussed in the context of=C2=A0service-oriented architecture,=C2=A0virtualization,=C2=A0provisioning<= /a>,=C2=A0converged infrastructur= e=C2=A0and dynamic=C2=A0datacenter=C2=A0topics. Orche= stration in this sense is about aligning the business request with the appl= ications, data, and infrastructure.[4]
    In the context of=C2=A0cloud computing, the= main difference between=C2=A0workflow auto= mation=C2=A0and orchestration is that workflows are processed and compl= eted as processes within a single domain for automation purposes, whereas o= rchestration includes a workflow and provides a directed action towards lar= ger goals and objectives.[1]
    In this context, and with the overall aim to achieve specific goals and= objectives (described through=C2=A0quality o= f service=C2=A0parameters), for example, meet application performance g= oals using minimized cost[5]=C2=A0and ma= ximize application performance within budget constraints.[6]







    On Tue, Aug 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com>= ; wrote:

    One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

    =C2=A0

    Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

    =C2=A0

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

    =C2=A0

    = From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
    Sent: Tuesday, August 11, 2020 8:44 AM
    To: Dave Tonge <dave.tonge@moneyhub.com>
    Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
    Subject: Re: [GNAP] Terminology

    =C2=A0

    the term "orchestator" does not match= any use case i have.

    Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

    Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

    1. the subject of the data to be transferred.

    2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

    3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

    4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

    5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

    =C2=A0

    This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

    Peace ..tom

    =C2=A0

    =C2=A0

    On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

    Hi all

    =C2=A0

    I agree that "client" can be confusing. I would = be in support of alternative terminology.

    We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

    =C2=A0

    Dave

    =C2=A0

    On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

    Hi Francis,

    =C2=A0

    I like your proposal, seems much more intuitive= .=C2=A0

    =C2=A0

    Fabien=C2=A0

    =C2=A0

    Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

    Hello Denis, Justin, Dick, Fabien,

    =C2=A0

    In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

    =C2=A0

    We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

    =C2=A0

    In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

    =C2=A0

    Best regards.

    /Francis

    =C2=A0

    On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

    I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

    =C2=A0

    I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

    =C2=A0

    /Dick

    =E1=90=A7=

    =C2=A0

    On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

    On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

    =C2=A0

    The term client in OAuth came from the computer= science definition of client-server interaction.

    =C2=A0

    This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

    =C2=A0

    =C2=A0=E2=80=94 Justin



    =C2=A0

    The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

    =C2=A0

    The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

    =C2=A0

    =C2=A0

    =C2=A0

    =E1=90=A7=

    =C2=A0

    On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

    Hi,=C2=A0

    =C2=A0

    To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

    =C2=A0

    As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

    =C2=A0

    Fabien=C2=A0

    =C2=A0

    On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

    Ju= stin and Dick,

    =C2=A0

    [W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

    =C2=A0

    So= let us attempt to define new terms:

    initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

    In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

    Re= source Owner (RO): entity capable of granting access to a protected resourc= e

    I = propose to replace it with Resource Manager (RM):

    Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

    D= enis

    =C2=A0

    I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

    =C2=A0

    Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

    =C2=A0

    For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

    =C2=A0

    /Dick

    =E1=90=A7=

    =C2=A0

    On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

    I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

    =C2=A0

    GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

    =C2=A0

    =C2=A0=E2=80=94 Justin



    On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

    =C2=A0

    I think that is fundamentally part of the quest= ion:

    We are clear that we are prod= ucing a protocol that is
    conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
    from OAuth 2.0 but with different definitions may lead to unnecessary
    confusion

    =C2=A0

    If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

    =C2=A0

    Food for thought.

    - Warren


    <= u>

    Warren Parad<= u>

    Founder, CTO=

    Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

    =C2=A0

    =C2=A0

    On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

    Hi Denis,

    On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
    > Hi Justin,
    >
    > Since you replied in parallel, I will make a response similar to the o= ne
    > I sent to Dick.
    >
    > > Hi Denis,
    > >
    > > I think there=E2=80=99s still a problem with the terminology in u= se here. What
    > > you describe as RS2, which might in fact be an RS unto itself, is= a
    > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
    > > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
    > > all the same as an OAuth client. I appreciate your mapping of the=
    > > entities below, but it makes it difficult to hold a discussion if= we
    > > aren=E2=80=99t using the same terms.
    > >
    > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
    > > our own terms. The bad news is that this is really hard to do. > >
    > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
    > > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
    >
    > In the ISO context, each document must define its own terminology. The=
    > boiler plate for RFCs does not mandate a terminology or definitions se= ction
    > but does not prevent it either. The vocabulary is limited and as long = as
    > we clearly define what our terms are meaning, we can re-use a term alr= eady
    > used in another RFC. This is also the ISO approach.

    Just because we can do something does not necessarily mean that it is a
    good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
    conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
    from OAuth 2.0 but with different definitions may lead to unnecessary
    confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
    use the term "GS" in XAuth, picking a name that was not already u= sed in
    OAuth 2.0.

    -Ben

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

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

    =C2=A0

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

    =C2=A0

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

    =C2=A0

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


    =C2=A0

    --

    Francis Pouatcha

    Co-Founder and Technical Lead

    adorsys GmbH & Co. KG

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

    =C2=A0

    =C2=A0

    Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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




    --000000000000f237e805ad0dd9da-- From nobody Mon Aug 17 01:05:12 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 27AD63A13EA for ; Mon, 17 Aug 2020 01:05:11 -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 OURfVFfu11tS for ; Mon, 17 Aug 2020 01:05:08 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 1FC5C3A13F1 for ; Mon, 17 Aug 2020 01:05:08 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id t15so16804510iob.3 for ; Mon, 17 Aug 2020 01:05:08 -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=zTzVpKbjOXbcErgsvLKzsjll+VttJ8Cx8l1r3QYN5q0=; b=OPlAL1SIrFKe5vNg9+PjDpzZSU0zjsuGOiz2JUQFGXuBtn4WdrVswxo9leWm461D+i MbWXpqtRh5aAoY3zucYDclqQkvu6YPQYyU5xKR92x+PYekwNrJE6rJF1n6k5nZ3rUvNc k9fcgW2+tjsR14ZXOm/pnohNPTA1lpwEBmpi1e0bdGPCRiDrbQ+M1ZlJrgaHbZsRck9b SPYE/WqzCaaEkMGn4ia7Dau6nPVBNKmRziqrY8j5stNzXk1lL5LQZTv1tz38Bpp4Hj28 b+0zdk9ztBjKK5ss+k2NLcJ8/JoF/j/Mii2UyHom6xnvsULZWOu//LeeNGVzkDpWA0ZS DXWw== 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=zTzVpKbjOXbcErgsvLKzsjll+VttJ8Cx8l1r3QYN5q0=; b=BBqJwVtQHirKtTxfnC7YJ2RqCADoFgraRqT/saOizguHvAC+uI6ZmP2BGJlyQ8VjDl Xxz/LQauAlgPpR1K3xaOqXLfCyJVObQC6rV1GR4JTUY2LShnyrWSNGsLIoCbNWz4aQZ6 ZTHsWL7knH0FeLpuQyVU/oMTjqHbTGI0oj2FtX1LxFvO8vTco329RvVZdxCF0gUaK0hN fLwy3h8xIytKCwDLoAMbWJsA3ZLysXYbQAebQcoGQTuNpPNLSMxVb2rDCRtw6xi/ZswN aQnY2Kbdcw1D2SrDPo7GaSqYya2rsDVKeRV/Pf3wG44dWpjwmGU6C+ay8eEmZdaY+Mt1 Z3cw== X-Gm-Message-State: AOAM530x/SWVJF+NimjArIOmdvdDpoDB+w7vUaNRQZwYPga9R9OZXmp7 PRn11zkU8poH+cGAEMHgbHA7b8EAokIfPihcBSQ= X-Google-Smtp-Source: ABdhPJyFyGz9V+c9bLZmDBXmZFgPjc9N7EueJd6vN5nQDY8KfP2OQGB0Lpf3KKth1si2OKGp5/VRg6pd6qlqZPv9Fss= X-Received: by 2002:a6b:e31a:: with SMTP id u26mr11078284ioc.162.1597651507265; Mon, 17 Aug 2020 01:05:07 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> In-Reply-To: From: Fabien Imbault Date: Mon, 17 Aug 2020 10:04:55 +0200 Message-ID: To: Dick Hardt Cc: Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000090c51205ad0e3a03" Archived-At: Subject: Re: [GNAP] User consent 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 08:05:11 -0000 --00000000000090c51205ad0e3a03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, They're not the same thing for me either. AND/OR conditions are logical operators, but it's the responsibility of the UI to display them however they wish. We still can discuss good practices of how the UI may look like (and which can be useful for reference implementations), but it's only informative in my opinion. An example of similar discussions: https://github.com/WICG/WebID/blob/master/design.md Fabien On Sun, Aug 16, 2020 at 10:28 PM Dick Hardt wrote: > Denis, a mathematical expression is not a user experience. > > While we may be able to standardize the result of a user experience, that > is not the same thing. > > On Fri, Aug 14, 2020 at 3:14 AM Denis wrote: > >> This is a new thread built from "Revisiting the photo sharing example (a >> driving use case for the creation of OAuth)" >> >> Hi Dick, >> >> I don't see how we can technically standardize a user experience, and it >> is not clear why a standard would be needed for interoperability. >> >> I already wrote a proposal and made it available to the mailing list. >> >> An access will be granted by a RS based on an mathematical expression >> which is formed using some combination of AND and OR conditions. >> >> Examples of combinations: >> >> *condition 1* AND >> *condition 2 condition 1* OR *condition 2* >> (*condition 1* AND *condition 2)* OR >> *condition 3 (condition 1* OR *condition 2)* AND *condition 3* >> >> The following notation is being used for the *conditions*: >> >> *condition x* =3D { AS identifier + set of attributes types } >> >> Each RS internally constructs an *authorization table* with the >> following content: >> >> 1=C2=B0 For the "authentication" operation: either FIDO U2F or a >> mathematical expression using conditions; >> >> 2=C2=B0 For any other operation: a mathematical expression using condit= ions. >> >> Given the operation selected by the client, the RS returns the >> appropriate mathematical expression and only the associated conditions >> used in that mathematical expression. The User may then decide whether >> they are appropriate to him or not. >> >> In many jurisdictions there are regulations regarding what information >> needs to be conveyed to a user, and potentially a consent requirement, >> for example a site explaining its use of cookies -- but I don't see how >> IETF would play a role in that. >> >> On a related note, the browsers attempted to standardize the username / >> password prompt, and that has been rejected by pretty much every site. >> The only site I've visited in the last decade that has used the browsers= ' >> built in username / password prompt was the W3C site -- and it was a >> frustrating >> experience since there was no button for account recovery -- it would >> just keep popping up. >> >> What I am proposing is unrelated to the two above cases you mention. >> >> Denis >> >> >> >> =E1=90=A7 >> >> On Thu, Aug 13, 2020 at 10:29 AM Denis wrote: >> >>> Dick, >>> >>> I think Tom's objection, and I agree with it, is that humans don't >>> interact in bits and bytes. >>> >>> I think it is useful to separate human interactions with software from >>> software interactions with software. >>> The latter we can standardize, the former we can call out as part of th= e >>> overall process, but it is not something >>> that is testable or required for interop, so I would argue human to >>> software interactions are NOT part of the protocol. >>> >>> I disagree. A set of a choices should be presented by the RS to the >>> Client in a standardized way. The choices made by the user >>> should be locally recorded by the Client, hence the RS does not need to >>> be informed of these choices. The RS will only know >>> the end result of these choices when/if it gets back one or more access >>> tokens. >>> >>> Human to software interactions should be part of the protocol. >>> >>> RS to Client: a set of choices >>> >>> Client to RS: Done (choices have been done by the user). >>> >>> Denis >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: >>> >>>> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure whe= re the objection >>>> you=E2=80=99re raising comes from. >>>> >>>> Also, whatever roles we define here, whether software or human-ware, >>>> they need to be related to the protocol. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>>> wrote: >>>> >>>> I strong object to the objectification of human users. It is way past >>>> time that the IETF becaume user oriented instead of web service orient= ed. >>>> users are human in my language. >>>> Peace ..tom >>>> >>>> >>>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >>>> >>>>> If defined as the party operating the client software, then the user >>>>> is a role. I believe this is more accurate and inclusive than the >>>>> definition you have proposed with the user as an entity. >>>>> >>>>> - Justin >>>>> ________________________________________ >>>>> From: Dick Hardt [dick.hardt@gmail.com] >>>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>>> To: Francis Pouatcha >>>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>>>> driving use case for the creation of OAuth) >>>>> >>>>> Hi Francis >>>>> >>>>> The user is an entity, not a role in the protocol in how I am definin= g >>>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>>> >>>>> I also think that (2) could be an extension to GNAP, rather than part >>>>> of the core protocol. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>>> > wrote: >>>>> In this context, I suggest we pick some words to work with, and >>>>> sharpen them as we move on, discover and map new use cases to the pro= tocol. >>>>> >>>>> In this diagram from the original thread ( >>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JO= GNw/), >>>>> I replaced the words: >>>>> >>>>> +-----------+ +--------------+ +----+ +----+ >>>>> +---------------------+ >>>>> | Requestor | | Orchestrator | | | | GS | | Resource >>>>> Controller | >>>>> | was | | was | | RS | | or | | was >>>>> | >>>>> | User | | Client | | | | AS | | Resource >>>>> Owner | >>>>> +-----------+ +--------------+ +----+ +----+ >>>>> +---------------------+ >>>>> |(1) ServiceRequest | | | | >>>>> |---------------------->| | | | >>>>> | |(2) ServiceIntent:AuthZChallenge | >>>>> | |<---------->| | | >>>>> | | | | | >>>>> | |(3) AuthZRequest(AuthZChallenge) | >>>>> | |------------------->| | >>>>> | | | |(4) >>>>> ConsentRequest:Grant >>>>> | | | |<-------------->| >>>>> | |(5) GrantAccess(AuthZ) | >>>>> | |<-------------------| | >>>>> | | | | | >>>>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>>>> | |<---------->| | | >>>>> |(7) ServiceResponse | | | | >>>>> |<----------------------| | | | >>>>> + + + + + >>>>> >>>>> The purpose of the GNAP protocol is to help negotiate access to a >>>>> protected resource. It starts with a requestor delegating activity to= an >>>>> orchestrator. These are all roles, no entities. Let focus on mapping = the >>>>> use cases to the protocol roles and interactions so wwe can discover = what >>>>> is missing. >>>>> >>>>> It seems cumbersome to use it in discussions as it is impossible to >>>>> give the word "Client" a clear definition. >>>>> >>>>> We can mention in the final document, that the "Orchestrator" (or >>>>> whatever word we finally use) plays the same role as the "Client" in = oAuth2. >>>>> >>>>> Best regards. >>>>> /Francis >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>>> > wrote: >>>>> I agree with Justin. Redefining well used terms will lead to >>>>> significant confusion. If we have a different role than what we have = had in >>>>> the past, then that role should have a name not being used already in= OAuth >>>>> or OIDC. >>>>> >>>>> Given what we have learned, and my own experience explaining what a >>>>> Client is, and is not, improving the definition for Client could prov= e >>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>> >>>>> For example, clarifying that a Client is a role an entity plays in th= e >>>>> protocol, and that the same entity may play other roles at other time= s, or >>>>> some other language to help differentiate between "role" and "entity"= . >>>>> >>>>> /Dick >>>>> [ >>>>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb2= 0%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90= =A7 >>>>> >>>>> >>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>>> jricher@mit.edu>> wrote: >>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a be= tter fit, but I=E2=80=99m >>>>> not really in favor of taking an existing term and applying a complet= ely >>>>> new definition to it. In other words, I would sooner stop using =E2= =80=9Cclient=E2=80=9D >>>>> and come up with a new, more specific and accurate term for the role = than >>>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely di= fferent. We did this >>>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserv= er=E2=80=9D on its own but instead >>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>> >>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>> ignore the fact that GNAP is going to be coming up in a world that is >>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t h= ave a blank >>>>> slate to work with, but neither are we bound to use the same terms an= d >>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>>> wparad@rhosys.ch>> wrote: >>>>> >>>>> I think that is fundamentally part of the question: >>>>> We are clear that we are producing a protocol that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion >>>>> >>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>> should not change the meanings of any definition. If we are saying th= is >>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick th= e best >>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I ha= ve a >>>>> lot of first hand experience of industries "ruining words", and attem= pting >>>>> to side-step the problem rather than redefining the word just confuse= s >>>>> everyone as everyone forgets the original meaning as new documents co= me >>>>> out, but the confusion with the use of a non-obvious word continues. >>>>> >>>>> Food for thought. >>>>> - Warren >>>>> >>>>> [ >>>>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdf= ZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6h= juIm9GCeBRRzrSc8kWcUSNtuA >>>>> ] >>>>> >>>>> Warren Parad >>>>> Founder, CTO >>>>> >>>>> Secure your user data and complete your authorization architecture. >>>>> Implement Authress. >>>>> >>>>> >>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>>> kaduk@mit.edu>> wrote: >>>>> Hi Denis, >>>>> >>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>> > Hi Justin, >>>>> > >>>>> > Since you replied in parallel, I will make a response similar to th= e >>>>> one >>>>> > I sent to Dick. >>>>> > >>>>> > > Hi Denis, >>>>> > > >>>>> > > I think there=E2=80=99s still a problem with the terminology in u= se here. >>>>> What >>>>> > > you describe as RS2, which might in fact be an RS unto itself, is= a >>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What >>>>> you >>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth worl= d, but it is not >>>>> at >>>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>>> > > entities below, but it makes it difficult to hold a discussion if >>>>> we >>>>> > > aren=E2=80=99t using the same terms. >>>>> > > >>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can >>>>> define >>>>> > > our own terms. The bad news is that this is really hard to do. >>>>> > > >>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>>> definitions, >>>>> > > but we=E2=80=99ve got a chance to be more precise with how we def= ine >>>>> things. >>>>> > >>>>> > In the ISO context, each document must define its own terminology. >>>>> The >>>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>>> section >>>>> > but does not prevent it either. The vocabulary is limited and as >>>>> long as >>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>> already >>>>> > used in another RFC. This is also the ISO approach. >>>>> >>>>> Just because we can do something does not necessarily mean that it is= a >>>>> good idea to do so. We are clear that we are producing a protocol >>>>> that is >>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>>> terms >>>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>> Dick to >>>>> use the term "GS" in XAuth, picking a name that was not already used = in >>>>> OAuth 2.0. >>>>> >>>>> -Ben >>>>> >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> 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/ >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000090c51205ad0e3a03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    They're not the sam= e thing for me either. AND/OR conditions are logical operators, but it'= s the responsibility=C2=A0of the UI to display them however they wish.
    =
    We still can discuss good practices of how the UI may look l= ike=C2=A0(and which can be useful for reference implementations), but it= 9;s only informative in my opinion.=C2=A0
    An example of similar d= iscussions:=C2=A0https://github.com/WICG/WebID/blob/master/design.md
    Fabien

    On Sun, Aug 16, 2020 at 10:28 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    <= div>Denis, a mathematical expression is not a user experience.
    While we may be able to standardize the result of a user exper= ience, that is not the same thing.=C2=A0

    On Fri, Aug 14, 2020 at 3:14 AM Den= is <denis.ietf@f= ree.fr> wrote:
    =20 =20 =20
    This is a new thread built from "R= evisiting the photo sharing example (a driving use case for the creation of OAuth)"

    Hi Dick,

    =20
    I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

    I already wrote a proposal and made it available to the mailing list.

    An access will be granted b= y a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

    Examples of combinations:

    condition 1 AND condition= 2
    condition 1     OR condition 2
    (condition 1 AND condition 2= ) OR condition 3
    (condition 1     OR condition 2) AND <= /span>condition 3    =

    The following notation is being used for the conditions:

    condition x =3D { AS identifier + set of attributes types }

    Each RS internally constructs an authorization table with the following content:

    1=C2=B0=C2=A0 For th= e "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

    2=C2=B0=C2=A0 For an= y other operation: a mathematical expression using conditions.

    Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
    used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

    =C2=A0In many jurisdictions there are regulations regarding wh= at information needs to be conveyed to a user, and potentially a consent requirement,
    for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that.=C2=A0

    On a related note, the browsers=C2=A0attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
    The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
    experience since there was no button for account recovery -- it would just keep popping up.

    What I am proposing is unrelated to the two above cases you mention.

    Denis



    3D""==E1=90=A7

    On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
    Dick,

    I think Tom's objection, and I agree wit= h it, is that humans don't interact in bits and bytes.=C2= =A0

    I think it is useful to separate human interactions with software from software interactions with software.
    The latter we can standardize, the former we can call out as part of the overall process, but it is not something
    that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

    I disagree.=C2=A0 A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
    should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
    the end result of these choices when/if it gets back one or more access tokens.

    Human to software interactions should be part of the protocol.

    RS to Client: a set of choices

    Client to RS: Done (choices have been done by the user).

    Denis



    3D""=E1=90=A7

    On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
    It=E2=80=99s a role fulfilled by a person, so I=E2= =80=99m not sure where the objection you=E2=80=99re raising comes f= rom.

    Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

    =C2=A0=E2=80=94 Justin

    On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

    I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
    users are human in my language.
    Peace ..tom


    On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
    If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

    =C2=A0- Justin
    ________________________________________
    From: Dick Hardt [dick.hardt@gmail.com]
    Sent: Tuesday, August 11, 2020 6:21 PM
    To: Francis Pouatcha
    Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
    Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

    Hi Francis

    The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

    I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





    On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
    In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

    In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_Kimj= OBJqdmQY-JOGNw/), I replaced the words:

    +-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
    | Requestor |=C2=A0 =C2=A0 =C2=A0 | Orc= hestrator |=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | GS |=C2=A0 | R= esource Controller |
    |=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    |=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |= =C2=A0 =C2=A0 Resource Owner=C2=A0 =C2=A0|
    +-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
    =C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2= =A0 =C2=A0|
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2= =A0 =C2=A0|
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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)= ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|<= ;-------------->|
    =C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |(7) ServiceResponse=C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

    The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

    It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clea= r definition.

    We can mention in the final document, that the "Orchestrator&q= uot; (or whatever word we finally use) plays the same role as the "Client= " in oAuth2.

    Best regards.
    /Francis





    On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
    I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

    Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

    For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role&q= uot; and "entity".

    /Dick
    [https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBn= bWFpbC5jb20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d5= 0e00dbac3a]=E1=90=A7

    On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
    I=E2=80=99m in favor of coming up with = a new term that=E2=80=99s a better fit, but I= =E2=80=99m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come= up with a new, more specific and accurate term for the role than to define =E2=80=9Ccl= ient=E2=80=9D as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cc= onsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2= =80=9D and =E2=80=9CResource Server=E2=80=9D.

    GNAP can do something similar, in my opinion. But what we can=E2=80=99t do i= s ignore the fact that GNAP is going to be coming up in a world that is already permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have = a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

    =C2=A0=E2=80=94 Justin

    On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

    I think that is fundamentally part of the question:
    We are clear that we are producing a protocol that is
    conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
    from OAuth 2.0 but with different definitions may lead to unnecessary
    confusion

    If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

    Food for thought.
    - Warren

    [https://lh6.googleusercontent.com/DNiDx1QGIr= SqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45= YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

    Warren Parad
    Founder, CTO

    Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p&g= t;.


    On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
    Hi Denis,

    On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
    > Hi Justin,
    >
    > Since you replied in parallel, I will make a response similar to the one
    > I sent to Dick.
    >
    > > Hi Denis,
    > >
    > > I think there=E2=80=99s still= a problem with the terminology in use here. What
    > > you describe as RS2, which might in fact be an RS unto itself, is a
    > > =E2=80=9CClient=E2=80=9D in O= Auth parlance because it is /a client of RS1/. What you
    > > call a =E2=80=9Cclient=E2=80= =9D has no analogue in the OAuth world, but it is not at
    > > all the same as an OAuth client. I appreciate your mapping of the
    > > entities below, but it makes it difficult to hold a discussion if we
    > > aren=E2=80=99t using the same terms.
    > >
    > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can define
    > > our own terms. The bad news is that this is really hard to do.
    > >
    > > In GNAP, we shouldn=E2=80=99t= just re-use existing terms with new definitions,
    > > but we=E2=80=99ve got a chanc= e to be more precise with how we define things.
    >
    > In the ISO context, each document must define its own terminology. The
    > boiler plate for RFCs does not mandate a terminology or definitions section
    > but does not prevent it either. The vocabulary is limited and as long as
    > we clearly define what our terms are meaning, we can re-use a term already
    > used in another RFC. This is also the ISO approach.

    Just because we can do something does not necessarily mean that it is a
    good idea to do so.=C2=A0 We are clear that we are producing a protocol that is
    conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
    from OAuth 2.0 but with different definitions may lead to unnecessary
    confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
    use the term "GS" in XAuth, p= icking a name that was not already used in
    OAuth 2.0.

    -Ben

    --
    Txauth mailing list
    Txauth@ietf.org<mailto:Txauth@ietf.org>
    https://www.ietf.org= /mailman/listinfo/txauth
    --
    Txauth mailing list
    Txauth@ietf.org<mailto:Txauth@ietf.org>
    https://www.ietf.org= /mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org<mailto:TXAuth@ietf.org>
    https://www.ietf.org= /mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org<mailto:TXAuth@ietf.org>
    https://www.ietf.org= /mailman/listinfo/txauth


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


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


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000090c51205ad0e3a03-- From nobody Mon Aug 17 03:56:22 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 CB56B3A149B for ; Mon, 17 Aug 2020 03:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3mYXrsRClA7D for ; Mon, 17 Aug 2020 03:56:16 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 BF6FF3A0B19 for ; Mon, 17 Aug 2020 03:56:15 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id k4so14074446ilr.12 for ; Mon, 17 Aug 2020 03:56:15 -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=3WlOV+OzM5wwODTrCji/WOh1acajABPDk7dLcWQq84I=; b=titpEZQRS9+tkPlCbkkH1zHRrY6ywExD/vz5npd7Hw17JMw0zBN6WGrWlZfURTOb2z wIbITjhfgzfhuLBh9WjBhBcd1UuhWBrM0v+4mTDRe8lLrXXuOYYEPKt1uH5H2UT8Ib2L dU8EdE1hLF1tvbwGQ0HOz8OTqbCiE+TAIG/cqtZjhxn6/AS2fbR2AMxqgfjwwPxERK11 8LWKQO+6VR5Xr7jlUYxeuHACxT3OSE1nG4V/nP1XTJRmRBFuV3dK4enbUd+IGTCmXggp yDyrVtQn/RtbPnqFZlxVNCTMIuV/5mXassMKmVNPau48TlAvIhSaEE7MICynBJjVSKK6 QxWg== 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=3WlOV+OzM5wwODTrCji/WOh1acajABPDk7dLcWQq84I=; b=ZG4biK/11vEs4JM1KzUcgdpk9mh9Sl+VoviRYXQkA45thi4qOW1Xo+zqR5Fy3q+pwq rZAHoieS7JbeN1ePX4rHeZ1pdyL27oIFE9qTKNyg91Zhr6MhhRjO+vHvE4SaeCM1RRlg /PZJxQhOiY0Je4wuOZaLyFDjB5izlol73/mb2bL6PzQuoVWR2nkMaQIVKbsj33LVj7Bs x4alwcwGcieqe8MBN4MV8tN+V75mvPGJdQRcI0002CZkN+AcAtCnV4lyc+PjXlQhNjWK L+gt/L6UHys3t0XuZ1vi8tpS1kkb6syCU+BOE3WdjUp4vafwxp1CutYsHBM0O5R/N0Dy WGUA== X-Gm-Message-State: AOAM532tE4Jr0OsFYIUgnPClvSLoTGgrSQKC/kdVMdtW0gZ+JuIeS3bD wJ6CKGuykYRfgAXkNVZ7fEcBrrz0LcB1A1VRrco= X-Google-Smtp-Source: ABdhPJyYdHqCMvYBbgrNMh7tW74tbsyOoUhe1iDCvpYaMapYu1bslWklNQbHVMfk/Wz/WM4ULArpxSZu5WW9tPAxR6c= X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr12236180ils.188.1597661774733; Mon, 17 Aug 2020 03:56:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 17 Aug 2020 12:56:03 +0200 Message-ID: To: Francis Pouatcha Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000008de83a05ad109ec0" 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 10:56:21 -0000 --0000000000008de83a05ad109ec0 Content-Type: text/plain; charset="UTF-8" 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. Depending on the situation, one may either require the GS to provide the front-channel, or decide to separate it. 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. Why mandate that interaction C shall always occur through a GS? (I'm sure Denis will not want this, for instance). 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?). 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? 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). 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). This I think makes it a very flexible model, while enabling what we're after. Fabien On Mon, Aug 17, 2020 at 4:38 AM Francis Pouatcha 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 > --0000000000008de83a05ad109ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Francis,=C2=A0

    I like that alt2 intr= oduces the additional discussions we had previously (on privacy and other t= opics) but I think this schema is too prescriptive.

    Depending on the situation, one may either require the GS to provide the = front-channel, or decide to separate it.
    Why mandate that interac= tion B shall always occur through the GC? If I' a GC, I could just as w= ell decide that it's enough to just separate the front-channel from the= GS, without handling it myself.=C2=A0
    Why mandate that interacti= on C shall always occur through a GS? (I'm sure Denis will not want thi= s, for instance).
    Are we sure we need to formally separate B and = C? This goes beyond previous discussions of separating the front and back c= hannels, and I don't really see the advantage (maybe there is: which us= e cases would be impossible to do otherwise?).=C2=A0

    So overall, I think Alt2 over-complexifies the situation. We need to rem= ain flexible.
    Why not simply have an (optional) way of separating= these flows from the GS?=C2=A0

    For instance, an (= optional) Interact Server (IS) could provide support for a decoupled front-= channel:=C2=A0
    - 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 c= an be his own, for instance). In case nothing is specified, the GS decides.= =C2=A0
     --0000000000008de83a05ad109ec0-- 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
    - 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 interactio= n, 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 t= herefore the end-user is not the one that is asked for consent / then of co= urse, if the RC logs in, he would be able to manage his consent policies).= =C2=A0

    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).
    This I think mak= es it a very flexible model, while enabling what we're after.=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,

    Th= anks for pointing this out. This is the new diagram where=C2=A0++++ refers= =C2=A0to what Endpoint/Human interaction 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 | 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| Cont= roller (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|
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 +-= -->| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-->| =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0|=C2=A0 =C2=A0 +-----= ---+ =C2=A0 =C2=A0 | =C2=A0 +--------+
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =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=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|
    =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:<= /font>
    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 o= f the discussion we have been having around privacy, GS as big brother, aso= ...

    P.S.: an authentication [RP]+++(A)+++>[GC] can be assu= med, 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.
    /Franci= s


    On Sun, Aug 16, 2020 at 7:04 PM Dick Hardt &l= t;dick.hardt@gmai= l.com> wrote:
    Hi Francis

    I was intentional in st= ating 1.3 that it is human interactions. The connection lines are '+=C2= =A0+=C2=A0+' 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 diagra= m 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 tech= nically specified. The User and RO are not roles in the protocol, but are e= ntities in the trust model.

    I debated keeping the = interactions abstract and not stating=C2=A0"what" happened in eac= h interaction, but thought that might be confusing at this stage or our dis= cussions.

    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 ne= ed 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 mode= l does change though.

    /Dick







    On= Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <fpo@adorsys.de> wrote:
    Hello Dick,=C2=A0my f= eedback below:

    1.2: Ex= cellent 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 p= rotocol. 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: &qu= ot;Resource Controller". In past discussions there was a consensus on = using "Resource Controller" instead.

    (B) I which the GS ne= ver interacts with the "Requesting Party" in a matter of obtainin= g a grant to a resource (many reasons: privacy, confidentiality, abstractio= n, ...). Generally the GS will need information (claims) about the "Re= questing Party" to proceed with the authorisation decision. In this ca= se, the GS can instruct the GC to obtain those claims. In some cases, claim= s on the "Requesting Party" will be obtained from another "A= uthorization Server" (AS). The word AS is intentionally chosen here. I= n this same login, the path (C0, C1) below will not only return the RC cons= ent, but might also return some claims on RC.

    ASs provide authentica= tion "of" and consent collection "from" End Users. End = users are in this case the Requesting Party, and the Resource Controller).<= br>
    The result can look like the modified diagram below. With this we ca= n address some privacy concerns 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|
    =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 +------------+

    (B0, B1) replace (B). Occur inside step (3= ), GS asks GC to collect the claims. GC contacts RP-AS to negotiate those= =C2=A0claims. But it is important to mention that those Claims-RP are not t= he target Grant being negotiated for the resource access. They are generall= y=C2=A0used by GS (and later RS) as input into performing authz decisions.<= /font>

    (C0, C1) replace (C). They occur=C2=A0after step (3) (Beware= of the difference=C2=A0to Bs that occur=C2=A0inside 3). This separation ad= dress the Big Brother problem we have been discussing in the list.

    Essential is to mention that in an instantiation of this model for oA= uth for example:
    - GS, RP-AS and = RC-AS might be the same entity.
    -= RP and RC might refer to the same "End User".=C2=A0
    =

    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 s= ome inputs into tickets or wiki pages (like use cases).

    1.4:
    The = Trust model introduces what I would rather call the trust framework. The pu= rpose of the trust framework will be to address topics mentioned in this se= ction. There is still a lot of discussion needed to have a structure for th= is section.


    1.5
    I suggest again we replace Human with "E= nd User" and still make them roles. This is:
    Terminology (Are all r= oles)
    =C2=A0 -> These roles can be borne by End Users
    =C2=A0 =C2= =A0 =C2=A0-> Requesting Party (RP)
    =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-&= gt; RC-AS

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

    Best regards
    /Francis

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

    I just pushed an updated version of XAuth:


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

    /Dick

    1.=C2=A0Introduct= ion

    EDITOR NOTE

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

    XAuth

    The use of GNAP in this d= ocument is not intended to be a declaration of it being endorsed by the GNA= P working group.

    This document describes the core Grant Negotiation = and Authorization Protocol (GNAP). The protocol supports the widely deploye= d 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 exte= nsions. Related documents include: GNAP - Advanced Features=C2=A0[GNAP_Advanced]=C2=A0and JOSE Authentication=C2=A0= [JOSE_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 cry= ptographic functions. Standards have emerged for signing and encrypting tok= ens with rich payloads (JOSE) that are widely deployed.

    =

    GNAP simplifies t= he overall architectural model, takes advantage of today's technology l= andscape, provides support for all the widely deployed use cases, offers nu= merous extension points, and addresses many of the security issues in OAuth= 2.0 by passing parameters securely between parties rather than via a brows= er 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

    T= he 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 Gra= nt Server negotiate the Grant. The Grant Server acquires authorization to g= rant 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 C= lient, the requested identity claims, and the requested resource access. Ex= tensions may define additional information to be included in the Grant Requ= est.

    <= h3 id=3D"gmail-m_3993451923099602247gmail-m_-3253219048718590634gmail-m_-74= 91335305061859892gmail-m_-5602902245930246723gmail-m_-8634122456003472927gm= ail-name-protocol-roles" style=3D"line-height:1.3;font-size:18px;padding-to= p:24px">1.2.=C2=A0Protoc= ol Roles

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

    (1) The GC m= ay query the RS to determine what the RS requires from a GS for resource ac= cess. 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 mech= anism 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=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 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 t= he User, or from the owner of the resources at the Resource Server, the Res= ource Owner (RO)

    Below is when the human interactions may occur in th= e 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. The addition of the h= uman interactions (A) - (C) are=C2=A0bolded=C2=A0below.

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

    (1) The GC may qu= ery the RS to determine what the RS requires from a GS for resource access<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.3-6" style=3D"text-decoration-line:none;color:rgb(102,102,102)" targe= t=3D"_blank">

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

    (3) The GC and GS ma= y negotiate the Grant

    (B) The GS may interact with the User f= or 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 author= ization. This interaction is not in scope of this document.<= /a>

    1.4.=C2=A0Trust Model

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

    • Client= Owner=C2=A0(CO) - the legal entity that owns the Grant Client.
    • Grant Server Owner=C2=A0(GSO) - the legal entity that own= s the Grant Server.
    • Claims Issuer=C2=A0(Issuer) - a leg= al entity that issues identity claims about the User. The Grant Server Owne= r 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 th= e 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 tru= sts 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 Gran= t 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 m= anage access to the RO resources

    1.5.=C2=A0= Terminology

    Roles

    • Grant Client=C2=A0(GC)

      • m= ay want access to resources at a Resource Server
      • may be interact= ing 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 Gra= nt requests from the GC for resource access and identity claims
      • negotiates the interaction mode with the GC if interaction is required wit= h the User
      • acquires authorization from the User before granting = identity claims to the GC
      • acquires authorization from the RO bef= ore granting resource access to the GC
      • grants resource access = and identity claims to the GC

    • Resource Server=C2=A0(RS)

    • =
    • expresses what th= e GC must obtain from the GS for access through documentation or an API. Th= is is not in scope for this document
    • verifies the GS granted acc= ess to the GC, when the GS makes resource access requests

    Humans

    • <= strong>User

      • the person interacting = with the Grant Client.
      • has delegated access to identity claims a= bout 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 indepe= ndently.

    Reused Terms

    • access token=C2= =A0- an access 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 Claim as defined in=C2=A0[OIDC<= /a>]=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[O= IDC]=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.
    • authN=C2=A0- short for authentication.
    • authZ=C2=A0- s= hort for authorization.

    New Terms

    • GS URI=C2=A0- the e= ndpoint at the GS the GC calls to create a Grant, and is the unique identif= ier 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 prov= e it possesses a key that is linked to the Client ID. The GS may have diffe= rent policies for what different Registered Clients can request. A Register= ed 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 it is the same instance of the GC o= n 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 th= e GS for a Dynamic Client for the Dynamic Client to refer to itself in subs= equent requests.
    • Interaction=C2=A0- how the GC directs = the User to interact with the GS. This document defines the interaction mod= es: "redirect", "indirect", and "user_code" i= n=C2=A0Section 5.
    • Grant=C2=A0- the = user identity claims and/or resource access the GS has granted to the Clien= t. 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 th= e GS URI.
    • Access=C2=A0- the access granted by the RO to= the GC and contains an access token. The GS may invalidate an Access at an= y time.
    • Access URI=C2=A0- the URI that represents the A= ccess the GC was granted by the RO. The Access URI MUST start with the GS U= RI.. 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


    --
    Francis Pouatcha
    Co-Founder and Technical Lead=
    adorsys GmbH & Co. KG
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    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-- From nobody Mon Aug 17 05:17: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 6729C3A14FC for ; Mon, 17 Aug 2020 05:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 6SnAuTV6ahnc for ; Mon, 17 Aug 2020 05:17:02 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 832B73A14F8 for ; Mon, 17 Aug 2020 05:17:02 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id v6so17274253iow.11 for ; Mon, 17 Aug 2020 05:17:02 -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=bGMLJZH18ECIjQ+Ww/kQh0DuscKcuoXF3ILLJHl+zLE=; b=Hb5imFgVU75JVb2V7J9K1hlRGOM0Rs/eleNJ//OEbITApIYwAV5zDTdrL1FRYT8WaV G1d5kMCPQetzP6fPxxCIEkibC4fQha1p1NwSfVrqDUptUO0F8sHM2k1MS+9mQoq9COgp WAsJ+IRl5aTuLj3GoKhX3jF8R1KCtgWVSZLdh2GNrnaD2F/1zh3rawo5v1er8luamDl7 X/pTfaQ1t97DoWGkODduMN7mrWHxaMwUaBZCNlekO8KG42sVVh6YqOFEx6/7QHDOE1Dr Qi9g8RCf0JVzfeDUfwukRxSKQI41YWLrFbmc7FziRkQM1LdpEZaUmCIYWux1DhipK4KM F6Pg== 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=bGMLJZH18ECIjQ+Ww/kQh0DuscKcuoXF3ILLJHl+zLE=; b=k5/iALzkTKcQIAb4jy8fW3vyanWN/LR0r4+gMV3WmaT934ply6TI+k22Lfta46jo67 MUZK2B7axXewge3hZ0LFQ3AmskVKYW2cTKw7T8nrhBm8gbVP0f5nwVPE4i1hFTxADS/V zaXkWnZy5oxtvHuqKUMpXvy4IKF8Nax/gJ1vH/XCBRkBkyJvtMLTau4y81X8aafZxwo4 dLABREv84Jfn9Flw7xsXI6lLf2JlcHaOnAbTHqQjEeY20LHxa95P+KgXJCugphjGX55s P/+VyaXi1Y5DbOg6UV9YKhLHltyZtQF+FBy/cVmftkgj5gN3mjIGMQqgSUhnjnQqtIJY mbeg== X-Gm-Message-State: AOAM532mqZkjOzRjqD/3CWksA41ozwgvJ9aOMiDZG5D6N3rpFyUlsWtr mK08jLSxGKfjK+eUqCrmJx8SlTggOrpF62twWgA= X-Google-Smtp-Source: ABdhPJyF/O+/M79rpknJeaB3A69anVr6Q1Srj1Y68aICjlSBG4WxqlSUwEYBSI4tRD3CfnOkjWM/MePNrJUnvSk7K+Y= X-Received: by 2002:a5d:841a:: with SMTP id i26mr11901259ion.144.1597666621508; Mon, 17 Aug 2020 05:17:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 17 Aug 2020 14:16:49 +0200 Message-ID: To: Francis Pouatcha Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000071d28005ad11bfa0" 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 12:17:08 -0000 --00000000000071d28005ad11bfa0 Content-Type: text/plain; charset="UTF-8" Hi Francis, Thanks for your comments. Mine are inline (marked with "FI"). I think most of that is clear now (except from the way to make it visible on a diagram). I'd actually like to focus more specifically on the previous exchange: 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. > In most cases, getting the asynchronous consent from the RC (distinct from the end-user) would be an issue (unless the end-user is ok to wait). > Here I guess you're considering the case where you want to interactively ask the RC (distinct from the end-user) to consent, instead of making a policy based decision. A practical scenario where we may encounter a synchronous consent request between distinct end-user/RP and RC: a patient has a medical appointment with a new doctor. The doctor needs to access the medical record of the patient. Here the doctor is the end-user/requestor and the patient is the RC. Since they're already interacting face to face (physically or through video), the patient takes his decision (yes/no for each requested item) as soon as the doctor asks him to provide some information. Is this type of synchronous interaction what you had in mind? As for SSI, I think there should be a dedicated use case. Cheers Fabien On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha wrote: > 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. > > FI ; yes > >> > >> 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. > FI : yes, although in practice most verified credentials are bundled with some claims about identity. Like I'm a student in a bar, I'm going to show the proof of age (instead of date of birth) but am still required to show my name too (or a picture, or whatever that proves I didn't get a proof which belongs to someone else). > > 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] > FI : this type of interaction with SSI wallets directly on the mobile device would be interesting to dig into. If it hasn't been done yet, we should add a use case. > > >> 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. > FI : problem is that if you show that, most people will assume it's mandatory (as least for the alt2 part). At least I think that's what most readers would assume from reading the schema. > 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. > FI : see discussion at the start of the message > > >> 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. > FI : yes. > > >> 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? > FI : let me think about it ;-) > > 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/ > --00000000000071d28005ad11bfa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hi Francis,=C2=A0

      Than= ks for your comments. Mine are inline (marked with "FI"). I think= most of that is clear now (except from the way to make it visible on a dia= gram).

      I'd actually like to focus more specifi= cally on the previous exchange:

      Are we sure we need = to formally separate B and C? This goes beyond previous discussions of sepa= rating the front and back channels, and I don't really see the advantag= e (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.

      &= gt; In most cases, getting the asynchronous=C2=A0consent from the RC (disti= nct from the end-user) would be an issue (unless the end-user is ok to wait= ).
      > Here I guess you're considering the = case where you want to interactively ask the RC (distinct from the end-user= ) to consent, instead of making a policy based decision.=C2=A0
      A practical scenario where we may encounter a synchronous cons= ent request between distinct end-user/RP and RC: a patient has a medical ap= pointment with a new doctor.
      The doctor needs to access the medic= al record of the patient. Here the doctor is the end-user/requestor and the= patient is the RC.
      Since they're already interacting face to= face (physically or through video), the patient takes his decision (yes/no= for each requested item) as soon as the doctor asks him to provide some in= formation.=C2=A0

      Is this type of synchronous inter= action what you had in mind?

      As for SSI, I think t= here should be a dedicated use case.=C2=A0

      <= div>Cheers
      Fabien


      On Mon, Aug 17, 2020 at 1:2= 8 PM Francis Pouatcha <fpo@adorsys.de<= /a>> wrote:
      <= div dir=3D"ltr">
      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.
      =

      FI ; yes=C2=A0
      <= div dir=3D"ltr">
      =C2=A0

      Depending o= n the situation, one may either require the GS to provide the front-channel= , or decide to separate it.
      Yes. This is why e= xposing RC-AS in the diagram makes that case visible. In those situations,= =C2=A0[GS]=3D[RC-AS]=3D[RP-AS]=3DGS resulting=C2=A0 in the original model o= f Dick.
      =C2=A0
      Why mandate that interaction B shall always occu= r 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 oAu= th2 model again. THis is what Dick has in the=C2=A0original diagram.
      <= div>
      There are some cases where GS might need to gain knowled= ge of some claims about RP, but do not need to know their identity. E.g.: a= ge(RP) > 18.=C2=A0
      In those cases [GS] --(3)-->[GC]++(B)++&= gt;[RP] makes sense.

      FI := yes, although in practice most verified credentials are bundled with some = claims about identity. Like I'm a student in a bar, I'm going to sh= ow the proof of age (instead of date of birth) but am still required to sho= w my name too (or a picture, or whatever that proves I didn't get a pro= of which belongs to someone else).=C2=A0 =C2=A0=C2=A0

      And in some cases RP-AS resides on RP's device (= SSI). And we find ourself with:
      [GS] --(3)-->[GC]-->(B0)--&= gt;[RP-AS]++(B1)++>[RP]

      FI : this type of interaction with SSI wallets directly on the mobile= device would be interesting to dig into. If it hasn't been done yet, w= e should add a use case.=C2=A0 =C2=A0
      =C2=A0
      Why mandate that interaction C shall always occur through a G= S? (I'm sure Denis will not want this, for instance).
      This is not a mandate, but an abstract model. In SSI/DID most o= f the time, RP-RC will also reside on a user device.

       --00000000000071d28005ad11bfa0-- From nobody Mon Aug 17 07:02:17 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 C873D3A0C4F for ; Mon, 17 Aug 2020 07:02:15 -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 QVq3aoSIc17h for ; Mon, 17 Aug 2020 07:02:11 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 DD09A3A0C4C for ; Mon, 17 Aug 2020 07:02:10 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id l2so15115084wrc.7 for ; Mon, 17 Aug 2020 07:02:10 -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=0c6ewdnhi47wH0V+3fG1R0aqr1YhvwbD4B5dTQ6VNOI=; b=UVDm4rNdIweatigkOFS8VoDqw+54BFK+sc3E10sY1OP8Jj1wLS0djkENEGov5qhQ2v KcjyVIlpgfsME2SSPUrsOMWMDnOkpTKFEu0aaw+WC6nB7ArSv/kR+Wi4JeuEgzjTeA6Y AafGIujtI/BnCE7Qea/fepapVMQqAlGkcXv6w= 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=0c6ewdnhi47wH0V+3fG1R0aqr1YhvwbD4B5dTQ6VNOI=; b=jr3oPtKlzpU852tFQZCJuDAXTMLx+FkM0+wfAT9d5cqtkLZGgAgs94sqwCHIrwMitA m8NgemQM0eVLNrExyKaSZ/ehHDhyu9U1yJiM3adwbamdFHsiTlAdIB9niiRaNICzKJJn F0vGQ2UgBONYTqwZsBezPVUyT3J9NzmCgetUgPVQuZb/qpy6BLxhLRfqg/QfM/yfT4q/ iLTYXTZI2jdckDk/sACl8A9JrAX6iYeqyKmOfpWJyS4jw7ULXx0ftV0yubBO8NiN4omR mU6mI+BjuVX03GsVX/CNxWOulPqkZPjrwJi/gEEXRATQbmXMz9tM2k+ecCneY7rZ3+nh NNEA== X-Gm-Message-State: AOAM530IwWxkFsoejjzkyDAvBQpIGjI7kxYAHRuk5MlTePnXW1f2AE2h fmNg09bBxrikfA0sRu76Duak5D7SbVrbtXBDvLaii17+e/4mWQ== X-Google-Smtp-Source: ABdhPJy4g4sVcVQEgqa221hI/sr81mJzbSyBuPpsWtUT4wl7fea3ZBEsPGugrBHn0Nc3TuSF5yTvrNGXOXP7lR2CvoU= X-Received: by 2002:a5d:51c3:: with SMTP id n3mr15918686wrv.104.1597672928897; Mon, 17 Aug 2020 07:02:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Mon, 17 Aug 2020 10:01:56 -0400 Message-ID: To: Fabien Imbault Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000065015d05ad133796" 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 14:02:16 -0000 --00000000000065015d05ad133796 Content-Type: text/plain; charset="UTF-8" Hello Fabian, On Mon, Aug 17, 2020 at 8:17 AM Fabien Imbault wrote: > Hi Francis, > > Thanks for your comments. Mine are inline (marked with "FI"). I think most > of that is clear now (except from the way to make it visible on a diagram). > > I'd actually like to focus more specifically on the previous exchange: > > 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. > > > In most cases, getting the asynchronous consent from the RC (distinct > from the end-user) would be an issue (unless the end-user is ok to wait). > > Here I guess you're considering the case where you want to interactively > ask the RC (distinct from the end-user) to consent, instead of making a > policy based decision. > > A practical scenario where we may encounter a synchronous consent request > between distinct end-user/RP and RC: a patient has a medical appointment > with a new doctor. > The doctor needs to access the medical record of the patient. Here the > doctor is the end-user/requestor and the patient is the RC. > Since they're already interacting face to face (physically or through > video), the patient takes his decision (yes/no for each requested item) as > soon as the doctor asks him to provide some information. > > Is this type of synchronous interaction what you had in mind? > Yes. There are a lot of such use cases in banking, government, health. > > As for SSI, I think there should be a dedicated use case. > > Cheers > Fabien > > > On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha wrote: > >> 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. >> >> FI ; yes > >> >>> >> >>> 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. >> > > FI : yes, although in practice most verified credentials are bundled with > some claims about identity. Like I'm a student in a bar, I'm going to show > the proof of age (instead of date of birth) but am still required to show > my name too (or a picture, or whatever that proves I didn't get a proof > which belongs to someone else). > RP-AS will verify RP identity and produce different RP-identifiers for each grant negotiation use case [GC,RS,GS], thereby preservice RP privacy and preventing correlations. > >> >> 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] >> > > FI : this type of interaction with SSI wallets directly on the mobile > device would be interesting to dig into. If it hasn't been done yet, we > should add a use case. > Yes... >> >>> 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. >> > > FI : problem is that if you show that, most people will assume it's > mandatory (as least for the alt2 part). At least I think that's what most > readers would assume from reading the schema. > Therefore it is essential to have Dick introduce the section 1.3 with the notion that this is an abstract model that might take a different concrete form for each problem domain (resp. trust model) errata: Above i meant [RP-AS will also reside on a user device] and not [RP-RC]. /Francis > > >> 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. >> > > FI : see discussion at the start of the message > >> >> >>> 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. >> > > FI : yes. > >> >> >>> 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? >> > > FI : let me think about it ;-) > > >> >> 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/ >> > -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --00000000000065015d05ad133796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hello Fabian,

      On Mon, Aug 17, 2020 at 8:17= AM Fabien Imbault <fabien.i= mbault@gmail.com> wrote:
      Hi Francis,=C2=A0
      Thanks for your comments. Mine are inline (marked with "FI= "). I think most of that is clear now (except from the way to make it = visible on a diagram).

      I'd actually like to fo= cus more specifically on the previous exchange:

      Are w= e sure we need to formally separate B and C? This goes beyond previous disc= ussions of separating the front and back channels, and I don't really s= ee 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.

      > In most cases, getting the asynchronous=C2=A0consent from = the RC (distinct from the end-user) would be an issue (unless the end-user = is ok to wait).
      > Here I guess you're con= sidering the case where you want to interactively ask the RC (distinct from= the end-user) to consent, instead of making a policy based decision.=C2=A0=

      A practical scenario where we may encounter a syn= chronous consent request between distinct end-user/RP and RC: a patient has= a medical appointment with a new doctor.
      The doctor needs to acc= ess the medical record of the patient. Here the doctor is the end-user/requ= estor and the patient is the RC.
      Since they're already intera= cting face to face (physically or through video), the patient takes his dec= ision (yes/no for each requested item) as soon as the doctor asks him to pr= ovide some information.=C2=A0

      Is this type of sync= hronous interaction what you had in mind?
      Yes. There are a lot of such use cases in banking, government, health.=C2= =A0

      As for SSI, I think there should be a= dedicated use case.=C2=A0

      Cheers
      =
      Fabien


      On Mon, Aug 17, 2020 at 1:28 PM Francis Pou= atcha <fpo@adorsys.d= e> wrote:
      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.
      =

      FI ; yes=C2=A0
      <= div dir=3D"ltr">
      =C2=A0

      Depending o= n the situation, one may either require the GS to provide the front-channel= , or decide to separate it.
      Yes. This is why e= xposing RC-AS in the diagram makes that case visible. In those situations,= =C2=A0[GS]=3D[RC-AS]=3D[RP-AS]=3DGS resulting=C2=A0 in the original model o= f Dick.
      =C2=A0
      Why mandate that interaction B shall always occu= r 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 oAu= th2 model again. THis is what Dick has in the=C2=A0original diagram.
      <= div>
      There are some cases where GS might need to gain knowled= ge of some claims about RP, but do not need to know their identity. E.g.: a= ge(RP) > 18.=C2=A0
      In those cases [GS] --(3)-->[GC]++(B)++&= gt;[RP] makes sense.

      FI := yes, although in practice most verified credentials are bundled with some = claims about identity. Like I'm a student in a bar, I'm going to sh= ow the proof of age (instead of date of birth) but am still required to sho= w my name too (or a picture, or whatever that proves I didn't get a pro= of which belongs to someone else).
      RP-AS= will verify RP identity and produce different RP-identifiers for each gran= t negotiation use=C2=A0case [GC,RS,GS], thereby preservice RP privacy and p= reventing correlations.

      =C2=A0 = =C2=A0=C2=A0

      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]

      FI : this type of interaction with = SSI wallets directly on the mobile device would be interesting to dig into.= If it hasn't been done yet, we should add a use case.=C2=A0 =C2=A0
      Yes...

      =C2=A0
      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 us= er device.

      FI : problem i= s that if you show that, most people will assume it's mandatory (as lea= st for the alt2 part). At least I think that's what most readers would = assume from reading the schema.
      Therefor= e it is essential to have Dick introduce the section 1.3 with the notion th= at this is an abstract model that might take a different concrete form for = each problem domain (resp. trust model)=C2=A0

      erra= ta: Above i meant [RP-AS will also reside on a user device] and not [RP-RC]= .
      /Francis


      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 woul= d be impossible to do otherwise?).=C2=A0
      We ha= ve a situation where RP =3D!=3D RC. And each of them have their own AS.

      FI : see discussion at the s= tart of the message=C2=A0


      So overall, I think Alt2 over-complexifies the situation. We need to rema= in flexible.
      Why not simply have an (optional) way of separating = these flows from the GS?=C2=A0
      With GNAP, we a= re at an abstraction=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.

      =
      FI : yes.=C2=A0=C2=A0


      For instance, an (optional) Interact Server (IS) could provide sup= port for a decoupled front-channel:=C2=A0
      - it does not change th= e 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 whi= ch IS it wants to use (it can be his own, for instance). In case nothing is= specified, the GS decides.=C2=A0
      - the IS is able to handle the = front-channel for idclaims and consent, and return back to the GS what acce= ss 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 en= d-user is not the RC, and therefore the end-user is not the one that is ask= ed for consent / then of course, if the RC logs in, he would be able to man= age his consent policies).=C2=A0
      What you ment= ion here is why I display RP-AS and 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 where 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?

      FI : let me think about it ;-)
      =C2=A0
      <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

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


      --
      Francis Pouatcha
      Co-= Founder and Technical Lead
      adorsys GmbH & Co. KG
      https://= adorsys-platform.de/solutions/
      --00000000000065015d05ad133796-- From nobody Tue Aug 18 01:58:02 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 71B773A07B3 for ; Tue, 18 Aug 2020 01:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 O1GJ036uTT-a for ; Tue, 18 Aug 2020 01:57:55 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 F0B4E3A07A9 for ; Tue, 18 Aug 2020 01:57:54 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id t13so16919013ile.9 for ; Tue, 18 Aug 2020 01:57:54 -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=D43qAfTxOlzuAa+df2GTJ+Q3zoEPMR4YVIXtqIHIXQ4=; b=stEYDN7RCsHwq8Qwu4cAf7k2Zi2JCll40Ns/xjwJX5XgDGvDD08HsZC1p+9ncAvOph AjccIE72Au3CkokO0qQ4yFdGSV75dM53iRaExpzQRfRekY1RhUswqtYAQk883kKlECHp YNFvQ9bRkVXf9EvDNv12RA+tF7NDP89h16LGj2URiBoc5rf1btMI4+meHe+sZa3HvZU1 MxYGJ0XQX7MMBdJCfpMTHhhWk2PiFJxYWt+o+f0e6dPZkeIIe8QAkuol09tzNF53vF++ FX+B/qWy5DZZildMBUtVlrQFUlrDKPJ2xJjff6ulb+QWR5So95uLqGAYno8shCDcgjTe MFbw== 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=D43qAfTxOlzuAa+df2GTJ+Q3zoEPMR4YVIXtqIHIXQ4=; b=lCsor21me33lRDD3g5Jv5CGm6SGiPnWbFOCEc9tmxvXeYA/+HDYbnClN89c1LSeJ0p N2ax4y0IcaS6/LckTtopeRh89YSSc79Mr7eUF3VBDhCFfp650tyyJgiCWrIlt1+myTcz suSHn+lrDFcM3GUq7x0Z37Dsh4+wa91iOCk4kHA8iNUIN/a9fayACnQwkcps+OxS5+pE Xd2VRRDfve8IRVKnLykfuEQ+whmBmlJZ2sbv1iKOV5szEa/4I+JIeFufzaGvjMz0eJ4K 8uZj33CAuW7ZsQjPPXZzMt2ASMn8UhUnC56rd+a9o6uvBTqpqipPaOAuzVd/GUiAhGXR C61A== X-Gm-Message-State: AOAM532n2XrbDHe+T4ku8Y/Pi4KijPAOJ4NYaGldNHHIVIUZYP/Gc6c7 +CtHtpiNEEOSec/WU2ONGAJCcHJzEncydSIuszM= X-Google-Smtp-Source: ABdhPJwrLJpWthDU2OEZaz2A/acXLgbkD0LqY5EWqs5iMm8UPhE1DOFgEykO6O1OwunlkjQBZi7cjlKUGYJYAfwfIJo= X-Received: by 2002:a92:480f:: with SMTP id v15mr16002622ila.123.1597741073970; Tue, 18 Aug 2020 01:57:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Tue, 18 Aug 2020 10:57:42 +0200 Message-ID: To: Francis Pouatcha Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000283ddb05ad231594" 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 08:58:01 -0000 --000000000000283ddb05ad231594 Content-Type: text/plain; charset="UTF-8" Hi Francis, To clarify the various interaction modes, I've entered a new use case: https://github.com/ietf-wg-gnap/general/wiki/Categories-of-interaction Compared to the other cases, I think the use case "User != RO and interact_mode = synchronous" is challenging, but SSI could be of great help. I've also entered a SSI use case: https://github.com/ietf-wg-gnap/general/wiki/SSI-integration (very high level, more as a reminder for now). Fabien On Mon, Aug 17, 2020 at 4:02 PM Francis Pouatcha wrote: > Hello Fabian, > > On Mon, Aug 17, 2020 at 8:17 AM Fabien Imbault > wrote: > >> Hi Francis, >> >> Thanks for your comments. Mine are inline (marked with "FI"). I think >> most of that is clear now (except from the way to make it visible on a >> diagram). >> >> I'd actually like to focus more specifically on the previous exchange: >> >> 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. >> >> > In most cases, getting the asynchronous consent from the RC (distinct >> from the end-user) would be an issue (unless the end-user is ok to wait). >> > Here I guess you're considering the case where you want to >> interactively ask the RC (distinct from the end-user) to consent, instead >> of making a policy based decision. >> >> A practical scenario where we may encounter a synchronous consent request >> between distinct end-user/RP and RC: a patient has a medical appointment >> with a new doctor. >> The doctor needs to access the medical record of the patient. Here the >> doctor is the end-user/requestor and the patient is the RC. >> Since they're already interacting face to face (physically or through >> video), the patient takes his decision (yes/no for each requested item) as >> soon as the doctor asks him to provide some information. >> >> Is this type of synchronous interaction what you had in mind? >> > Yes. There are a lot of such use cases in banking, government, health. > >> >> As for SSI, I think there should be a dedicated use case. >> >> Cheers >> Fabien >> >> >> On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha wrote: >> >>> 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. >>> >>> FI ; yes >> >>> >>>> >>> >>>> 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. >>> >> >> FI : yes, although in practice most verified credentials are bundled with >> some claims about identity. Like I'm a student in a bar, I'm going to show >> the proof of age (instead of date of birth) but am still required to show >> my name too (or a picture, or whatever that proves I didn't get a proof >> which belongs to someone else). >> > RP-AS will verify RP identity and produce different RP-identifiers for > each grant negotiation use case [GC,RS,GS], thereby preservice RP privacy > and preventing correlations. > > >> >>> >>> 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] >>> >> >> FI : this type of interaction with SSI wallets directly on the mobile >> device would be interesting to dig into. If it hasn't been done yet, we >> should add a use case. >> > Yes... > > >>> >>>> 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. >>> >> >> FI : problem is that if you show that, most people will assume it's >> mandatory (as least for the alt2 part). At least I think that's what most >> readers would assume from reading the schema. >> > Therefore it is essential to have Dick introduce the section 1.3 with the > notion that this is an abstract model that might take a different concrete > form for each problem domain (resp. trust model) > > errata: Above i meant [RP-AS will also reside on a user device] and not > [RP-RC]. > /Francis > >> >> >>> 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. >>> >> >> FI : see discussion at the start of the message >> >>> >>> >>>> 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. >>> >> >> FI : yes. >> >>> >>> >>>> 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? >>> >> >> FI : let me think about it ;-) >> >> >>> >>> 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/ >>> >> > > -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ > --000000000000283ddb05ad231594 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hi Francis,=C2=A0

      To clarify the variou= s interaction modes, I've entered a new use case:=C2=A0https://= github.com/ietf-wg-gnap/general/wiki/Categories-of-interaction
      Compared to the other cases, I think the use case "User !=3D RO and = interact_mode =3D synchronous" is challenging, but SSI could be of gre= at help.=C2=A0

      I've also entered a SSI use= case:=C2=A0https://github.com/ietf-wg-gnap/general/wiki/SSI-integration= =C2=A0(very high level, more as a reminder for now).=C2=A0

      Fabien

      On Mon, Aug 17, 2020 at 4:02 PM Francis Pouatcha <<= a href=3D"mailto:fpo@adorsys.de">fpo@adorsys.de> wrote:
      Hello Fabian,

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

      Thanks for your comments. Mine are inline (marked with "FI"). I= think most of that is clear now (except from the way to make it visible on= a diagram).

      I'd actually like to focus more s= pecifically on the previous exchange:

      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 adv= antage (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.

      > In most cases, getting the asynchronous=C2=A0consent from the RC (di= stinct from the end-user) would be an issue (unless the end-user is ok to w= ait).
      > Here I guess you're considering t= he case where you want to interactively ask the RC (distinct from the end-u= ser) to consent, instead of making a policy based decision.=C2=A0

      A practical scenario where we may encounter a synchronous c= onsent request between distinct end-user/RP and RC: a patient has a medical= appointment with a new doctor.
      The doctor needs to access the me= dical record of the patient. Here the doctor is the end-user/requestor and = the patient is the RC.
      Since they're already interacting face= to face (physically or through video), the patient takes his decision (yes= /no for each requested item) as soon as the doctor asks him to provide some= information.=C2=A0

      Is this type of synchronous in= teraction what you had in mind?
      Yes. The= re are a lot of such use cases in banking, government, health.=C2=A0
      <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

      As for SSI, I think there should be a dedicate= d use case.=C2=A0

      Cheers
      Fabi= en


      On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha <= ;fpo@adorsys.de>= wrote:
      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 discussions we had p= reviously (on privacy and other topics) but I think this schema is too pres= criptive.
      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 entity. This m= eans the oAuth2 instantiated model might look very simple.

      FI ; yes=C2=A0
      =C2=A0

      Depending on the situa= tion, 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,=C2=A0[GS]= =3D[RC-AS]=3D[RP-AS]=3DGS resulting=C2=A0 in the original model of Dick.
      =C2=A0
      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=C2=A0original 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.=C2=A0
      In those cases [GS] --(3)-->[GC]++(B)++>[RP] ma= kes sense.

      FI : yes, alth= ough in practice most verified credentials are bundled with some claims abo= ut identity. Like I'm a student in a bar, I'm going to show the pro= of of age (instead of date of birth) but am still required to show my name = too (or a picture, or whatever that proves I didn't get a proof which b= elongs to someone else).
      RP-AS will veri= fy RP identity and produce different RP-identifiers for each grant negotiat= ion use=C2=A0case [GC,RS,GS], thereby preservice RP privacy and preventing = correlations.

      =C2=A0 =C2=A0= =C2=A0

      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]

      FI : this type of interaction with SSI wa= llets directly on the mobile device would be interesting to dig into. If it= hasn't been done yet, we should add a use case.=C2=A0 =C2=A0
      Yes...

      =C2=A0
      Why mandate that interaction C sh= all always occur through a GS? (I'm sure Denis will not want this, for = instance).
      This is not a mandate, but an abstr= act model. In SSI/DID most of the time, RP-RC will also reside on a user de= vice.

      FI : problem is tha= t if you show that, most people will assume it's mandatory (as least fo= r the alt2 part). At least I think that's what most readers would assum= e from reading the schema.
      Therefore it = is essential to have Dick introduce the section 1.3 with the notion that th= is is an abstract model that might take a different concrete form for each = problem domain (resp. trust model)=C2=A0

      errata: A= bove i meant [RP-AS will also reside on a user device] and not [RP-RC].
      /Francis

      <= div>
      Are we sure we need to formally separate B and C? This goes beyo= nd previous discussions of separating the front and back channels, and I do= n'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.

      FI : see discussion at the start = of the message=C2=A0


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

      FI : yes.=C2=A0=C2=A0


      <= div>For instance, an (optional) Interact Server (IS) could provide support = for a decoupled front-channel:=C2=A0
      - it does not change the int= eraction between a GC and a GS. It does change the trust model though, depe= nding 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 spec= ified, the GS decides.=C2=A0
      - the IS is able to handle the front= -channel for idclaims and consent, and return back to the GS what access to= kens are required.
      - notice that although the IS is focused on fr= ont-channel interaction, there are cases where the consent needs to be base= d on policies instead of a direct human interaction (typically when end-use= r is not the RC, and therefore the end-user is not the one that is asked fo= r consent / then of course, if the RC logs in, he would be able to manage h= is consent policies).=C2=A0
      What you mention h= ere is why I display RP-AS and RC-AS!
      =C2=A0
      So ther= e's really no obligation that B occurs through the GC and C occurs thro= ugh the GS. It depends on where your front-channel is located (GC, GS, thir= d-party).
      Yes. I agree with=C2=A0you. How can = we make this=C2=A0 visible in a diagram?

      FI : let me think about it ;-)
      =C2=A0

      This I think makes it a very flexible model, while= 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<= /a>> wrote:
      <= div dir=3D"ltr">Hello Dick,

      <= div>
      Thanks for pointing this out. This is the= new diagram where=C2=A0++++ refers=C2=A0to what Endpoint/Human interaction= 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 | Reques= ting =C2=A0| =C2=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|
      =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 +--->| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 +-->| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
      =C2=A0 =C2=A0 =C2=A0 = =C2=A0 + =C2=A0|=C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 | =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 = + (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=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 Ser= ver =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 k= now what is part of the protocol:
      Alt-1: only (1..6). This is what you specified in section 1.2, and I am fi= ne with that.
      Alt-2: Alt-1=C2=A0+= =C2=A0(B0, C0). This is a result of the discussion we have been having arou= nd privacy, GS as big brother, aso....

      P.S.: an authenticatio= n [RP]+++(A)+++>[GC] can be assumed, but shall be irrelevant for the pro= tocol. [RP]+++(B1)+++>[RP-AS] is important for later instantiation of th= e model. As in many cases, like in oAuth [RP-AS] could be the same entity l= ike [GS].

      /Francis


      <= div class=3D"gmail_quote">
      On Sun, Aug= 16, 2020 at 7:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Francis

      =
      I was intentional in stating 1.3 that it is human interactions. = The connection lines are '+=C2=A0+=C2=A0+' rather than '-----&#= 39; to indicate that it is a human interaction rather than a protocol betwe= en roles. We can't specify how a human interaction works, but we can sh= ow 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 no= t roles in the protocol, but are entities in the trust model.
      I debated keeping the interactions abstract and not 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 represent the author= ization and the consent for the GC to pass to the GS, but the roles and ent= ities stay the same. The trust model does change though.

      /Dick







      On Sun, Aug 16, 2020 at 3:46 PM Francis Po= uatcha <fpo@adorsys.= de> wrote:
      Hello Dick,=C2=A0my feedback below:

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

      1.3:
      Title: Human Int= eraction -> End User Interaction
      I would title this "End User&qu= ot; interaction and not "human ...". It is not about having a hum= an, 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 u= sed by UMA.

      Participant: "Resource Controller". In past di= scussions there was a consensus on using "Resource Controller" in= stead.

      (B) I which the GS never interacts with the "Requesting = Party" in a matter of obtaining a grant to a resource (many reasons: p= rivacy, confidentiality, abstraction, ...). Generally the GS will need info= rmation (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" wi= ll be obtained from another "Authorization Server" (AS). The word= AS is intentionally chosen here. In this same login, the path (C0, C1) bel= ow will not only return the RC consent, but might also return some claims o= n RC.

      ASs provide authentication "of" and consent collecti= on "from" End Users. End users are in this case the Requesting Pa= rty, and the Resource Controller).

      The result can look like the modi= fied diagram below. With this we can address some privacy concerns 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|
      =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|<= br>=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) repl= ace (B). Occur inside step (3), GS asks GC to collect the claims. GC contac= ts RP-AS to negotiate those=C2=A0claims. But it is important to mention tha= t those Claims-RP are not the target Grant being negotiated for the resourc= e access. They are generally=C2=A0used by GS (and later RS) as input into p= erforming authz decisions.

      (C0, C1) replace (C). They occur= =C2=A0after step (3) (Beware of the difference=C2=A0to Bs that occur=C2=A0i= nside 3). This separation address the Big Brother problem we have been disc= ussing in the list.

      Essential is to mention that in an instan= tiation 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 Us= er".=C2=A0

      Off-topic: Th= e splitting of GS and AS was suggested in some discussions on the mailing l= ist. But we have no mean yet to isolate good inputs for later reuse. This i= s 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 neede= d to have a structure for this section.


      1.5
      I suggest again w= e replace Human with "End User" and still make them roles. This i= s:
      Terminology (Are all roles)
      =C2=A0 -> These roles can be borne = by End Users
      =C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)
      =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 fund= amental 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 = <dick.hardt@gm= ail.com> wrote:
      =
      Hello

      I just pushed an updat= ed 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 introdu= ction included below for your convenience

      /Dick

      1.= =C2=A0Introduction

      EDITOR NOTE

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

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

      This document describes the co= re Grant Negotiation and Authorization Protocol (GNAP). The protocol suppor= ts the widely deployed use cases supported by OAuth 2.0=C2=A0[R= FC6749]=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 Fea= tures=C2=A0[GNAP_Advanced]=C2=A0and JOSE Authe= ntication=C2=A0[JOSE_Authentication]=C2= =A0that describes the JOSE mechanisms for client authentication.

      The technology landscape h= as 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 ar= chitectural model, takes advantage of today's technology landscape, pro= vides support for all the widely deployed use cases, offers numerous extens= ion points, and addresses many of the security issues in OAuth 2.0 by passi= ng parameters securely between parties rather than via a browser redirectio= n.

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

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

      =

      1.1.=C2=A0The Grant<= /h3>

      The Grant is at the center of= the protocol between a client and a server. A Grant Client requests a Gran= t from a Grant Server. The Grant Client and Grant Server negotiate the Gran= t. 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 m= odes 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 Role= s

      There are three roles i= n GNAP: the Grant Client (GC), the Grant Server (GS), and the Resource Serv= er (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 Gra= nt=C2=A0Section 3.2). How the GC authenticates to the GS is n= ot 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=A0Section 4.1).

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

      (6) The RS evaluates acce= ss granted by the GS to determine access granted to the GC. This step is no= t in scope for this document.

      1.3.=C2=A0Hum= an Interactions

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

      Below is w= hen 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 a= s=C2=A0Section 1.2. The addition of the human interactions = (A) - (C) are=C2=A0bolded=C2=A0below.

      (A) The User is interact= ing with a GC, and the GC needs resource access and/or identity claims (a G= rant)

      (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 b= y the GS to determine access granted to the GC

      Alternatively, the Resource Owner cou= ld be a legal entity that has a software component that the Grant Server in= teracts with for Grant authorization. This interaction is not in scope of t= his document.

      1.4.=C2=A0Trust Model

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

      • Client Owner=C2=A0(CO) - the legal enti= ty 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 m= ay 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 Resour= ce 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 acq= uire 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 t= he RO resources

      1.5.=C2=A0Terminology

      Roles

      • Grant Client=C2=A0(GC)

        • may want access to resources at a Resource Server
        • may be i= nteracting 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<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#sec= tion-1.5-2.2.2.1" style=3D"text-decoration-line:none;color:rgb(102,102,102)= " target=3D"_blank">
        • negoti= ates the interaction mode with the GC if interaction is required with the U= ser
        • acq= uires authorization from the User before granting identity claims to the GC=
        • acquir= es authorization from the RO before granting resource access to the GC
        • grants reso= urce access and identity claims to the GC
        =

      • Resource Ser= ver=C2=A0(RS)

      H= umans

      • 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)

        • <= /ul>

        Reused Terms=

        • access token=C2=A0- an acc= ess 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 Claim as defined in=C2=A0[OIDC]=C2=A0Section 5. Cla= ims are issued by a Claims Issuer.
        • Client ID=C2=A0- a GS unique identifi= er 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 Numer= icDate as defined in=C2=A0[RFC7519]=C2=A0Section 2.<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.5-6.5" style=3D"text-decoration-line:none;color:rgb(102,102,102)" tar= get=3D"_blank">
        • authN=C2=A0- short for authent= ication.
        • authZ=C2=A0- short for authorization.

          • New Terms

          • GS URI=C2=A0- the endpoint a= t the GS the GC calls to create a Grant, and is the unique identifier for t= he 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 i= s linked to the Client ID. The GS may have different policies for what diff= erent Registered Clients can request. A Registered Client MAY be interactin= g 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 it i= s 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 compo= nent is an example of a Dynamic Client.
          • Client Handle=C2=A0- a unique i= dentifier 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 claim= s and/or resource access the GS has granted to the Client. The GS MAY inval= idate a Grant at any time.
          • Grant URI=C2=A0- the URI that represents the G= rant. The Grant URI MUST start with the GS URI.
            • Access=C2=A0- the access= granted by the RO to the GC and contains an access token. The GS may inval= idate an Access at any time.
          • Access URI=C2=A0- the URI that represents th= e Access the GC was granted by the RO. The Access URI MUST start with the G= S URI.. The Access URI is used to refresh an access token.
      <= /div>


      --
      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


      --
      Francis Pouatcha
      Co-Founder and Technical Lead=
      adorsys GmbH & Co. KG
      --000000000000283ddb05ad231594-- From nobody Tue Aug 18 03:22:24 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 389F73A07F6 for ; Tue, 18 Aug 2020 03:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no autolearn_force=no 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 7ipyljfcueXQ for ; Tue, 18 Aug 2020 03:22:21 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E7D3A07EC for ; Tue, 18 Aug 2020 03:22:20 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d67 with ME id GyNH2300P2bcEcA03yNJpa; Tue, 18 Aug 2020 12:22:19 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 18 Aug 2020 12:22:19 +0200 X-ME-IP: 90.79.51.120 To: "txauth@ietf.org" From: Denis Message-ID: <94edca87-ee06-566e-a71a-d6a902ee2684@free.fr> Date: Tue, 18 Aug 2020 12:22:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------760637E3710E2C672C191D5E" Content-Language: en-GB Archived-At: Subject: [GNAP] Enterprise servers and Internet servers use cases 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 10:22:23 -0000 This is a multi-part message in MIME format. --------------760637E3710E2C672C191D5E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, I have posted a new use case (unfortunately as usual for me in the wrong directory) under the name: * Enterprise servers and Internet servers use cases*. It is available from: https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases At the end of this paper, I have summarized the terminology used in this paper. * User : human person * individual client : application that requests access tokens on behalf of a User * User Agent : User Interface associated with an individual client that manages the User Consent and choices * enterprise client: application that requests access tokens on behalf of the application * attribute: characteristic of a User or of an Application * capability: pair of elements granted by an AS that indicates which method is allowed on which data object * Attribute-based Access Control (ABAC): access control scheme based on a policy that uses one or more attributes to grant or to deny an operation * User access token: access token that contains attributes related to the User or /and capabilities granted to the User * application access token: access token that contains attributes related to the application or /and capabilities granted to an enterprise client application Denis PS. If some one could post a message explaining how to place a use case in the right directory, it might be useful for a next time.  :-) --------------760637E3710E2C672C191D5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Hello,

      I have posted a new use case (unfortunately as usual for me in the wrong directory) under the name:
      Enterprise servers and Internet servers use cases      .

      It is available from: https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases

      At the end of this paper, I have summarized the terminology used in this paper.

      • User : human person
      • individual client : application that requests access tokens on behalf of a User
      • User Agent : User Interface associated with an individual client that manages the User Consent and choices
      • enterprise client: application that requests access tokens on behalf of the application
      • attribute: characteristic of a User or of an Application
      • capability: pair of elements granted by an AS that indicates which method is allowed on which data object
      • Attribute-based Access Control (ABAC): access control scheme based on a policy that uses one or more attributes to grant or to deny an operation
      • User access token: access token that contains attributes related to the User or /and capabilities granted to the User
      • application access token: access token that contains attributes related to the application or /and capabilities granted to an enterprise client application

      Denis

      PS. If some one could post a message explaining how to place a use case in the right directory, it might be useful for a next time.  :-)




      --------------760637E3710E2C672C191D5E-- From nobody Tue Aug 18 03:48:49 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 620E03A0839 for ; Tue, 18 Aug 2020 03:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 1kzNx7s_niw2 for ; Tue, 18 Aug 2020 03:48:45 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 A18D63A083D for ; Tue, 18 Aug 2020 03:48:45 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id q14so17180556ilj.8 for ; Tue, 18 Aug 2020 03:48:45 -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=sv4pO2X/+QWxIX5A18L8Z/SJPbczsOUWMU1Xn3Vr9w4=; b=aq/K/a64vmR9ke9EmdbdCy64QGJDhXqG+tudBFvZIoaWsOS09DFwTDMQ83oGlfxBOz ARCH4IyjY44/vFKNJZyvJOrb8xWZMtOpRwH4jiWadr2k8fZwzdyGnWWFpiquusNrTt9U kVda1y8gWSuViceYfvItf/vGbXlIGyoDmbCocGkhfR1qGgXaw4B4fqlJDa2xCo+X6JRh FmR2NKcMO59mn96Ic1WMJQHL6DiRQlzESo88TCBFGWSgEj5k9T2F8ViD5z1nQuRrAn6h TgsKvak3tqiYpRNGSeUg3z7JGEvGimfsar55/JmW/2RAVa5oQr4ENkafsHVerr+BApAT WDMw== 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=sv4pO2X/+QWxIX5A18L8Z/SJPbczsOUWMU1Xn3Vr9w4=; b=JxU7IkvU+mx0b0QAqtDQHcOY34P2lnEe5YPQiZmCB7nYzYjrz4bYZ3n244lqhU8FYa OewBSqirQoipncsyxRnmYPG1342zzUGi5clBrT9HlNhsjP9BmnXSRlqhW6jmIhzfez+c zVYoAc4b05xg+IJmaxU1s7jLbhOMz4wc4I9mLF0IBPs7XTt7wguXoD+3Hpucl1yb21Rf tnfgeod/081OGJOHlU4zufk0iuB54YxiHiNXDv2NJqhxx3Jumx2HxcA0p1bV+8QkRxfi 0N7Zfcaxm+F0D8s+EOx3UOF1mNOsB9Kuc39yghRF0LsAaOxpXrUVQZLZWnKlkiUUahW2 P0Vg== X-Gm-Message-State: AOAM530D4jUp+audHz7Vpd6o2NqumMMkb0BAOojXZcG9SGMV9Lr67nvK eqC6CrXreXDp5F/87dddMRJGEL4GigWI+EtgY24= X-Google-Smtp-Source: ABdhPJz7NjpKEyKVsSaVSqlEjf0okaMrU2ieuDqwH8/Ez6q+oH9fNEoIbFSY7jgt1VDtCMxsF3uLwGJ3g1rQbztXNNg= X-Received: by 2002:a92:c092:: with SMTP id h18mr17821276ile.178.1597747724728; Tue, 18 Aug 2020 03:48:44 -0700 (PDT) MIME-Version: 1.0 References: <94edca87-ee06-566e-a71a-d6a902ee2684@free.fr> In-Reply-To: <94edca87-ee06-566e-a71a-d6a902ee2684@free.fr> From: Fabien Imbault Date: Tue, 18 Aug 2020 12:48:33 +0200 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000092bfe105ad24a159" Archived-At: Subject: Re: [GNAP] Enterprise servers and Internet servers use cases 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 10:48:47 -0000 --00000000000092bfe105ad24a159 Content-Type: text/plain; charset="UTF-8" Hi Denis, If I understand correctly, your use case is about supporting ABAC, which is nice and should be fairly easy to do. I think you could make the use case much simpler, however. The description is currently very misleading. You're using the term "capability" is a sense that is very different from the context in which it is used by everyone else (i.e. ocaps litterature). I actually don't really understand why you want to use that term here. RBAC vs ABAC pros and cons are already well known (see for instance https://www.dnsstuff.com/rbac-vs-abac-access-control), and you don't really need to introduce capabilities into the mix. Fabien On Tue, Aug 18, 2020 at 12:22 PM Denis wrote: > Hello, > > I have posted a new use case (unfortunately as usual for me in the wrong > directory) under the name: > * Enterprise servers and Internet servers use cases*. > > It is available from: > https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases > > At the end of this paper, I have summarized the terminology used in this > paper. > > - User : human person > - individual client : application that requests access tokens on > behalf of a User > - User Agent : User Interface associated with an individual client > that manages the User Consent and choices > - enterprise client: application that requests access tokens on behalf > of the application > - attribute: characteristic of a User or of an Application > - capability: pair of elements granted by an AS that indicates which > method is allowed on which data object > - Attribute-based Access Control (ABAC): access control scheme based > on a policy that uses one or more attributes to grant or to deny an > operation > - User access token: access token that contains attributes related to > the User or /and capabilities granted to the User > - application access token: access token that contains attributes > related to the application or /and capabilities granted to an enterprise > client application > > Denis > > PS. If some one could post a message explaining how to place a use case in > the right directory, it might be useful for a next time. :-) > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000092bfe105ad24a159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hi Denis,=C2=A0

      If I understand correct= ly, your use case is about supporting ABAC, which is nice and should be fai= rly easy to do. I think you could make the use case much simpler, however.<= /div>

      The description is=C2=A0currently=C2=A0very mislea= ding. You're using the term "capability" is a sense that is v= ery different from the context in which it is used by everyone else (i.e. o= caps litterature). I actually don't really understand why you want to u= se that term here. RBAC vs ABAC pros and cons are already well known (see f= or instance=C2=A0https://www.dnsstuff.com/rbac-vs-abac-access-control), and you d= on't really need to introduce capabilities into the mix.=C2=A0

      Fabien

      On Tue, Aug 18, 2020 at 12:22 PM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20

      Hello,

      I have posted a new use case (unfortunately as usual for me in the wrong directory) under the name:
      Enterprise servers and Internet servers use cases      .

      It is available from: https://github.com/ietf-wg-gnap/general/wiki/En= terprise-servers-and-Internet-servers-use-cases

      At the end of this paper, I have summarized the terminology used in this paper.

      • User : human person
      • individual client : application that requests access tokens on behalf of a User
      • User Agent : User Interface associated with an individual client that manages the User Consent and choices
      • enterprise client: application that requests access tokens on behalf of the application
      • attribute: characteristic of a User or of an Application
      • capability: pair of elements granted by an AS that indicates which method is allowed on which data object
      • Attribute-based Access Control (ABAC): access control scheme based on a policy that uses one or more attributes to grant or to deny an operation
      • User access token: access token that contains attributes related to the User or /and capabilities granted to the User
      • application access token: access token that contains attributes related to the application or /and capabilities granted to an enterprise client application

      Denis

      PS. If some one could post a message explaining how to place a use case in the right directory, it might be useful for a next time.=C2=A0 :-)




      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --00000000000092bfe105ad24a159-- From nobody Tue Aug 18 06:52:23 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 F0FCD3A0A63 for ; Tue, 18 Aug 2020 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 D7goSr89a-L4 for ; Tue, 18 Aug 2020 06:52:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257CD3A0A62 for ; Tue, 18 Aug 2020 06:52:19 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d89 with ME id H1sG2300A2bcEcA031sGZn; Tue, 18 Aug 2020 15:52:17 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 18 Aug 2020 15:52:17 +0200 X-ME-IP: 90.79.51.120 To: Fabien Imbault Cc: "txauth@ietf.org" References: <94edca87-ee06-566e-a71a-d6a902ee2684@free.fr> From: Denis Message-ID: Date: Tue, 18 Aug 2020 15:52:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5C8EE4289507F4983C86EB81" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Enterprise servers and Internet servers use cases 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 13:52:22 -0000 This is a multi-part message in MIME format. --------------5C8EE4289507F4983C86EB81 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, > Hi Denis, > > If I understand correctly, your use case is about supporting ABAC, > which is nice and should be fairly easy to do. I think you could make > the use case much simpler, however. The most complex case is being addressed where a RS is trusting more than one AS and is willing, using ABAC, to obtain different attributes for the same user. From there, simplifications exist in the real world. The most important is that I propose a single model where both capabilities and ABAC can be used, at the full discretion of the Resource Controller. > The description is currently very misleading. You're using the term > "capability" is a sense that is very different from the context in > which it is used by everyone else I am using the term "capability" since it is fully appropriate. A capability is a pair of elements granted by an AS that indicates "which method is allowed on which data object". In another context, I would say "which operation (e.g. read or write) is allowed on which data". > (i.e. ocaps litterature). I actually don't really understand why you > want to use that term here. I am sorry, but I don't know what ocaps means. I used: https://acronyms.thefreedictionary.com/OCAPS and I got the following results :    OCAPS    Office of Clinical Administrative and Program Support (Illinois)    OCAPS    Ohio Coalition for Adult Protective Services (Columbus, OH)    OCAPS    Out of Control Action Plans    OCAPS    Ottawa Citizens against Pollution by Sewage (Canada) I do mean capability. Please, take a look at: https://prosuncsedu.wordpress.com/2014/08/21/comparing-object-centric-access-control-mechanisms-acl-capability-list-attribute-based-access-control/ > RBAC vs ABAC pros and cons are already well known (see for instance > https://www.dnsstuff.com/rbac-vs-abac-access-control), and you don't > really need > to introduce capabilities into the mix. My argumentation has nothing to do about RBAC versus ABAC. Denis > > Fabien > > On Tue, Aug 18, 2020 at 12:22 PM Denis > wrote: > > Hello, > > I have posted a new use case (unfortunately as usual for me in the > wrong directory) under the name: * > Enterprise servers and Internet servers use cases*. > > It is available from: > https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases > > At the end of this paper, I have summarized the terminology used > in this paper. > > * User : human person > * individual client : application that requests access tokens on > behalf of a User > * User Agent : User Interface associated with an individual > client that manages the User Consent and choices > * enterprise client: application that requests access tokens on > behalf of the application > * attribute: characteristic of a User or of an Application > * capability: pair of elements granted by an AS that indicates > which method is allowed on which data object > * Attribute-based Access Control (ABAC): access control scheme > based on a policy that uses one or more attributes to grant or > to deny an operation > * User access token: access token that contains attributes > related to the User or /and capabilities granted to the User > * application access token: access token that contains > attributes related to the application or /and capabilities > granted to an enterprise client application > > Denis > > PS. If some one could post a message explaining how to place a use > case in the right directory, it might be useful for a next time.  :-) > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------5C8EE4289507F4983C86EB81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Fabien,

      Hi Denis, 

      If I understand correctly, your use case is about supporting ABAC, which is nice and should be fairly easy to do. I think you could make the use case much simpler, however.

      The most complex case is being addressed where a RS is trusting more than one AS and is willing, using ABAC, to obtain different attributes for the same user.
      From there, simplifications exist in the real world.

      The most important is that I propose a single model where both capabilities and ABAC can be used, at the full discretion of the Resource Controller.

      The description is currently very misleading. You're using the term "capability" is a sense that is very different from the context in which it is used by everyone else

      I am using the term "capability" since it is fully appropriate. A capability is a pair of elements granted by an AS that indicates "which method is allowed on which data object".
      In another context, I would say "which operation (e.g. read or write) is allowed on which data".

      (i.e. ocaps litterature). I actually don't really understand why you want to use that term here.

      I am sorry, but I don't know what ocaps means. I used: https://acronyms.thefreedictionary.com/OCAPS and I got the following results :

         OCAPS    Office of Clinical Administrative and Program Support (Illinois)
         OCAPS    Ohio Coalition for Adult Protective Services (Columbus, OH)
         OCAPS    Out of Control Action Plans
         OCAPS    Ottawa Citizens against Pollution by Sewage (Canada)

      I do mean capability. Please, take a look at:
      https://prosuncsedu.wordpress.com/2014/08/21/comparing-object-centric-access-control-mechanisms-acl-capability-list-attribute-based-access-control/

      RBAC vs ABAC pros and cons are already well known (see for instance https://www.dnsstuff.com/rbac-vs-abac-access-control), and you don't really need
      to introduce capabilities into the mix.

      My argumentation has nothing to do about RBAC versus ABAC.

      Denis


      Fabien

      On Tue, Aug 18, 2020 at 12:22 PM Denis <denis.ietf@free.fr> wrote:

      Hello,

      I have posted a new use case (unfortunately as usual for me in the wrong directory) under the name:
      Enterprise servers and Internet servers use cases      .

      It is available from: https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases

      At the end of this paper, I have summarized the terminology used in this paper.

      • User : human person
      • individual client : application that requests access tokens on behalf of a User
      • User Agent : User Interface associated with an individual client that manages the User Consent and choices
      • enterprise client: application that requests access tokens on behalf of the application
      • attribute: characteristic of a User or of an Application
      • capability: pair of elements granted by an AS that indicates which method is allowed on which data object
      • Attribute-based Access Control (ABAC): access control scheme based on a policy that uses one or more attributes to grant or to deny an operation
      • User access token: access token that contains attributes related to the User or /and capabilities granted to the User
      • application access token: access token that contains attributes related to the application or /and capabilities granted to an enterprise client application

      Denis

      PS. If some one could post a message explaining how to place a use case in the right directory, it might be useful for a next time.  :-)




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


      --------------5C8EE4289507F4983C86EB81-- From nobody Tue Aug 18 07:11:17 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 117BD3A0A7D for ; Tue, 18 Aug 2020 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 hyllESqOHs2h for ; Tue, 18 Aug 2020 07:11:13 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 44C2C3A0A83 for ; Tue, 18 Aug 2020 07:11:13 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id p18so13883457ilm.7 for ; Tue, 18 Aug 2020 07:11:13 -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=ZhbqqyhJmIHXhI2dYgJi+Oj5hisXUZHP9qPYjZWPSig=; b=jgykChZzxNYv/1b1uLEEuUYDqxmm1FWkmfwJr0+L8FSj/DRNvlLbfqMUAPCLcXDqXG LAgvwMpxap1hIyJnKWq5lcNqtqVppUr1DpjVAGhsSOZCf0ZQ9fb/MQT0IHn1jVAAbbCO l7Apw7H2kvHknvIHqxGVDTdalbQmFNR+b5JbWvH0RnjoMaDexH2uzCqahad/gQpBxBOA 3O+olu/ZIzeJWa2QIYBVhW1MhnSGF2fS1rav5PbWMP9MmvC68kHfajoaWY9CzuLHPlWU RKUzYqFcdl++zDABOTU4lLcPy6eR79soDvt5atVYdScL74ClnfJwheAeIJnL39zip78z rFGg== 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=ZhbqqyhJmIHXhI2dYgJi+Oj5hisXUZHP9qPYjZWPSig=; b=KjXtv3Z7RW498NMWX7PIW3xlKLdcMTe+jDKEtnZ43N1SqvyDNt0cV6PDYTv4ULvlqm 5DPzHNo3UKQAc/1FerbKaujY356mLpmLrdX+B21p1CYEoBmBO7bPxWwLrMxj4fJFWj/x 1Map1G+BbPiJYpmFUUOZekMdqNd8g+AANuwMk5rMgr1z+MJqZlEKNv/gOOMDnAtmc6eA B8mHHRSv0uPoIwaSOmAcqAW7b5NhDPr0C4oBjAyl9C/B20DKgYdcz/1evxKlgth+/wmb +fKutPZGduk8ZWEWb/pSkKusG+CAfgu3jQ3VkYOuldTvBjgqJVKzGE5DWTAs/PJcywaq zncw== X-Gm-Message-State: AOAM530zoD1Z0j37ewWsn/OR9lh4DTVKWpFzNlNRO0uyeCD6ACojqBDb H9luI+gm1mInRAYYRMckMH3KPrbW5Y9b87LQs/4m8rln6uWWKg== X-Google-Smtp-Source: ABdhPJyt9bqTngFeZeSSGmuoE+aetJJJRdQXfohe8llfACqeDDcYbdgnMNf1qjSoqdolvqpFCG+N762mcXnMcHoug4U= X-Received: by 2002:a92:bb0e:: with SMTP id w14mr16454214ili.68.1597759872441; Tue, 18 Aug 2020 07:11:12 -0700 (PDT) MIME-Version: 1.0 References: <94edca87-ee06-566e-a71a-d6a902ee2684@free.fr> In-Reply-To: From: Fabien Imbault Date: Tue, 18 Aug 2020 16:11:00 +0200 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a2232105ad2775e4" Archived-At: Subject: Re: [GNAP] Enterprise servers and Internet servers use cases 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 14:11:15 -0000 --000000000000a2232105ad2775e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, You may read for instance : http://habitatchronicles.com/2017/05/what-are-capabilities/ Defined more specifically as ocaps =3D object capabilities, an alternative = to ACLs. The canonical example is the valey key for a car. If your argument is not about RBAC vs ABAC, I haven't understood what you're looking for. But unless you define it, the term=E2=80=9Ccapabilities= =E2=80=9D itself is quite confusing. What's your main concern? Fabien On Tue, Aug 18, 2020 at 3:52 PM Denis wrote: > Hi Fabien, > > Hi Denis, > > If I understand correctly, your use case is about supporting ABAC, which > is nice and should be fairly easy to do. I think you could make the use > case much simpler, however. > > The most complex case is being addressed where a RS is trusting more than > one AS and is willing, using ABAC, to obtain different attributes for the > same user. > From there, simplifications exist in the real world. > > The most important is that I propose a single model where both > capabilities and ABAC can be used, at the full discretion of the Resource > Controller. > > The description is currently very misleading. You're using the term > "capability" is a sense that is very different from the context in which = it > is used by everyone else > > I am using the term "capability" since it is fully appropriate. A > capability is a pair of elements granted by an AS that indicates "which > method is allowed on which data object". > In another context, I would say "which operation (e.g. read or write) is > allowed on which data". > > (i.e. ocaps litterature). I actually don't really understand why you want > to use that term here. > > I am sorry, but I don't know what ocaps means. I used: > https://acronyms.thefreedictionary.com/OCAPS and I got the following > results : > > OCAPS Office of Clinical Administrative and Program Support > (Illinois) > OCAPS Ohio Coalition for Adult Protective Services (Columbus, OH) > OCAPS Out of Control Action Plans > OCAPS Ottawa Citizens against Pollution by Sewage (Canada) > > I do mean capability. Please, take a look at: > > https://prosuncsedu.wordpress.com/2014/08/21/comparing-object-centric-acc= ess-control-mechanisms-acl-capability-list-attribute-based-access-control/ > > RBAC vs ABAC pros and cons are already well known (see for instance > https://www.dnsstuff.com/rbac-vs-abac-access-control), and you don't > really need > to introduce capabilities into the mix. > > My argumentation has nothing to do about RBAC versus ABAC. > > Denis > > > Fabien > > On Tue, Aug 18, 2020 at 12:22 PM Denis wrote: > >> Hello, >> >> I have posted a new use case (unfortunately as usual for me in the wrong >> directory) under the name: >> * Enterprise servers and Internet servers use cases*. >> >> It is available from: >> https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Inte= rnet-servers-use-cases >> >> At the end of this paper, I have summarized the terminology used in this >> paper. >> >> - User : human person >> - individual client : application that requests access tokens on >> behalf of a User >> - User Agent : User Interface associated with an individual client >> that manages the User Consent and choices >> - enterprise client: application that requests access tokens on >> behalf of the application >> - attribute: characteristic of a User or of an Application >> - capability: pair of elements granted by an AS that indicates which >> method is allowed on which data object >> - Attribute-based Access Control (ABAC): access control scheme based >> on a policy that uses one or more attributes to grant or to deny an >> operation >> - User access token: access token that contains attributes related to >> the User or /and capabilities granted to the User >> - application access token: access token that contains attributes >> related to the application or /and capabilities granted to an enterpr= ise >> client application >> >> Denis >> >> PS. If some one could post a message explaining how to place a use case >> in the right directory, it might be useful for a next time. :-) >> >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a2232105ad2775e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hi Denis,=C2=A0

      You may read for instan= ce :=C2=A0http://habitatchronicles.com/2017/05/what-are-capabilities/
      Defined more specifically as ocaps =3D object capabilities, an altern= ative to ACLs.=C2=A0
      The canonical example is the valey=C2=A0key = for a car.

      If your argument is not about RBAC vs A= BAC, I haven't understood what you're looking for. But unless you d= efine it, the term=E2=80=9Ccapabilities=E2=80=9D itself is quite confusing.=
      What's your main concern?

      Fabien

      On Tue, Aug 18, 2020 at 3:52 PM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20
      Hi Fabien,

      =20
      Hi Denis,=C2=A0

      If I understand correctly, your use case is about supporting ABAC, which is nice and should be fairly easy to do. I think you could make the use case much simpler, however.

      The most complex case is being addressed where a RS is trusting more than one AS and is willing, using ABAC, to obtain different attributes for the same user.
      From there, simplifications exist in the real world.

      The most important is that I propose a single model where both capabilities and ABAC can be used, at the full discretion of the Resource Controller.

      The description is=C2=A0currently=C2=A0very misleading. You= 9;re using the term "capability" is a sense that is very different= from the context in which it is used by everyone else

      I am using the term "capability" since it is fully appropr= iate. A capability is a pair of elements granted by an AS that indicates "which method is allowed on which data object".
      In another context, I would say "which operation (e.g. read or write) is allowed on which data".

      (i.e. ocaps litterature). I actually don't really understand why you want to use that term here.

      I am sorry, but I don't know what ocaps means. I used: https://acronyms.thefreedictionary.com/OCAPS and I got the following results :

      =C2=A0=C2=A0 OCAPS=C2=A0=C2=A0=C2=A0 Office of Clinical Administrativ= e and Program Support (Illinois)
      =C2=A0=C2=A0 OCAPS=C2=A0=C2=A0=C2=A0 Ohio Coalition for Adult Protect= ive Services (Columbus, OH)
      =C2=A0=C2=A0 OCAPS=C2=A0=C2=A0=C2=A0 Out of Control Action Plans
      =C2=A0=C2=A0 OCAPS=C2=A0=C2=A0=C2=A0 Ottawa Citizens against Pollutio= n by Sewage (Canada)

      I do mean capability. Please, take a look at:
      https://prosuncse= du.wordpress.com/2014/08/21/comparing-object-centric-access-control-mechani= sms-acl-capability-list-attribute-based-access-control/

      RBAC vs ABAC pros and cons are already well known (see for instance=C2=A0https://www.dnsstuff.com/rbac-vs-abac-acces= s-control), and you don't really need
      to introduce capabilities into the mix.

      My argumentation has nothing to do about RBAC versus ABAC.

      Denis


      Fabien

      On Tue, Aug 18, 2020 at 12:22 PM Denis <denis.ietf@free.fr> wrote:

      Hello,

      I have posted a new use case (unfortunately as usual for me in the wrong directory) under the name:
      Enterprise servers and Internet servers use cases      .

      It is available from: https://github.com/ietf-wg-gnap/general= /wiki/Enterprise-servers-and-Internet-servers-use-cases

      At the end of this paper, I have summarized the terminology used in this paper.

      • User : human person
      • individual client : application that requests access tokens on behalf of a User
      • User Agent : User Interface associated with an individual client that manages the User Consent and choices
      • enterprise client: application that requests access tokens on behalf of the application
      • attribute: characteristic of a User or of an Application
      • capability: pair of elements granted by an AS that indicates which method is allowed on which data object
      • Attribute-based Access Control (ABAC): access control scheme based on a policy that uses one or more attributes to grant or to deny an operation
      • User access token: access token that contains attributes related to the User or /and capabilities granted to the User
      • application access token: access token that contains attributes related to the application or /and capabilities granted to an enterprise client application

      Denis

      PS. If some one could post a message explaining how to place a use case in the right directory, it might be useful for a next time.=C2=A0 :-)




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


      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --000000000000a2232105ad2775e4-- From nobody Tue Aug 18 09:37:55 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 20F0C3A0F39 for ; Tue, 18 Aug 2020 09:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WBQYR_oPg_Tx for ; Tue, 18 Aug 2020 09:37:52 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6E13A0F38 for ; Tue, 18 Aug 2020 09:37:27 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d24 with ME id H4dQ230062bcEcA034dQ8B; Tue, 18 Aug 2020 18:37:25 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 18 Aug 2020 18:37:25 +0200 X-ME-IP: 90.79.51.120 To: nadalin@prodigy.net, txauth@ietf.org References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> <015801d67245$933b3850$b9b1a8f0$@prodigy.net> From: Denis Message-ID: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> Date: Tue, 18 Aug 2020 18:37:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <015801d67245$933b3850$b9b1a8f0$@prodigy.net> Content-Type: multipart/alternative; boundary="------------0482D3D4B006832E99D1A6C2" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Support of FIDO 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 16:37:54 -0000 This is a multi-part message in MIME format. --------------0482D3D4B006832E99D1A6C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tony, > > Not quite Dennis, the U2F device does not store the private key, it > only creates the private key. > Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf Extract:  (...) the ASPSP  (Account Servicing Payment Service Providers) server sends a challenge message to the authenticator which is then cryptographically signed by a *private key stored in the authenticator.* Denis > *From:* TXAuth *On Behalf Of *Denis > *Sent:* Friday, August 14, 2020 3:04 AM > *To:* nadalin@prodigy.net; txauth@ietf.org > *Subject:* Re: [GNAP] Support of FIDO > > Hi Tony, > > Dennis, not all the way correct > > * It is also possible to get rid of IDs and passwords using > FIDO. FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS > > Depends on if you only consider “private information” PII, there > can be all sorts of information passed in ClientData field of the > FIDO response, not desirable but perfectly OK > > * None of these two semantics fit with the FIDO use case where > the subject value is scoped to be locally unique in the > context of one RS. > Hence, the linkage of users between two RSs (or between one RS > and any other server) becomes impossible > > There is nothing that prohibits the RS from sharing registration > information between RS > > I am speaking of FIDO U2F where there are two main phases: > registration and authentication. > > The U2F device gives the public key and a Key Handle to the origin > online service or website during the user registration step. > Later, when the user performs an authentication, the origin online > service or website sends the Key Handle back to the U2F device > via the browser. The U2F device uses the Key Handle to identify > the user's private key, and creates a signature which is sent back > to the origin to verify the presence of the U2F device. Thus, the > Key Handle is simply an identifier of a particular key on the U2F > device. > > There is no other registration information needed. Sharing such an > information between RSs does not allow to link user accounts. > > Denis > > *From:* TXAuth > *On Behalf Of *Denis > *Sent:* Thursday, August 13, 2020 10:31 AM > *To:* txauth@ietf.org > *Subject:* [GNAP] Support of FIDO > > This topic has already been tackled on the list, but I open a new > thread for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and > passwords. Since the solution in OAuth 2.0 was to use access tokens, > there have been used everywhere, even when they were not strictly > needed. > > > It is also possible to get rid of IDs and passwords using FIDO. > FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS. > > > FIDO should be one allowed possibility for the user > authentication. In the case of FIDO, the user is authenticated > under a pseudonym > specific to the RS. It may observed that there is no equivalent in > OAuth because of the two different semantics of the subject claim. > > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is the > subject of the JWT.  The claims in a JWT are normally > statements about the subject. > The subject value MUST either be scoped to be locally unique > in the context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two users > between two RSs (i.e. using a locally unique identifier in the > context of the issuer) > while in the other case (i.e. using a globally unique identifier) > it is possible, in addition, to link the subject claim between one > RS and any other server > (i.e. not supporting OAuth) that is using the same globally unique > identifier. > > > None of these two semantics fit with the FIDO use case where the > subject value is scoped to be locally unique in the context of one > RS. > > Hence, the linkage of users between two RSs (or between one RS and > any other server) becomes impossible. > > > There are cases where a user would like to enjoy the > unlinkeability properties of FIDO which cannot be met using the > claims currently defined in OAuth. > > > Denis > --------------0482D3D4B006832E99D1A6C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Tony,

      Not quite Dennis, the U2F device does not store the private key, it only creates the private key.

      Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:

      https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf

      Extract:

       (...) the ASPSP  (Account Servicing Payment Service Providers) server sends a challenge message to the authenticator
      which is then cryptographically signed by a private key stored in the authenticator.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Friday, August 14, 2020 3:04 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO

       

      Hi Tony,

      Dennis, not all the way correct

      • It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
        and no trust relationships need to be defined since there is no AS

      Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

      • None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
        Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible

      There is nothing that prohibits the RS from sharing registration information between RS

      I am speaking of FIDO U2F where there are two main phases: registration and authentication.

      The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
      Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
      via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back
      to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

      There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Thursday, August 13, 2020 10:31 AM
      To: txauth@ietf.org
      Subject: [GNAP] Support of FIDO

       

      This topic has already been tackled on the list, but I open a new thread for it.

      In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
      there have been used everywhere, even when they were not strictly needed.


      It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
      and no trust relationships need to be defined since there is no AS.


      FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
      specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.


      RFC 7519 states:

      The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
      The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

      In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
      while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
      (i.e. not supporting OAuth) that is using the same globally unique identifier.


      None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

      Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.


      There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.


      Denis

       


      --------------0482D3D4B006832E99D1A6C2-- From nobody Tue Aug 18 09:46:57 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 632763A0F5A for ; Tue, 18 Aug 2020 09:46:56 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alkaline-solutions.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 TT4187wp4onn for ; Tue, 18 Aug 2020 09:46:54 -0700 (PDT) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0867A3A0F53 for ; Tue, 18 Aug 2020 09:46:53 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 2DA10385FBB; Tue, 18 Aug 2020 16:46:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1597769211; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mzEcT+fAPkQABGyoc+fEcJQhrjDczTU1JWtuJ8N2mG0=; b=P5Ci2NGghOHNeN1Pl2qFQt1yP9BOBi+RMmiW27rhwGpYULfyhlSE4JruuAqXcyTWi0LBLu 0AQqtb218svT5XngY4BAIqHgt3T3OSdo9M/zmROK+GEWlkrTtgjvoHBidL4MfSmIvjcLd/ xYZYK3bppUiEEiQtMeRU2VoPMDnW36U= Content-Type: multipart/alternative; boundary=Apple-Mail-8E24F815-72A2-4385-A573-9375AD112970 Content-Transfer-Encoding: 7bit From: David Mime-Version: 1.0 Date: Tue, 18 Aug 2020 10:46:47 -0600 Message-Id: <0E8FCF98-F5E7-4C1D-8491-96CFEF7AA3C4@alkaline-solutions.com> References: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> Cc: nadalin@prodigy.net, txauth@ietf.org In-Reply-To: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> To: Denis ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1597769213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mzEcT+fAPkQABGyoc+fEcJQhrjDczTU1JWtuJ8N2mG0=; b=ipNy2jFnAZb0S7yyX7J874Xg/kRpyU621m7gNt0wX49HC003KJrpcnGcL744yITvRVyqBv hy2O4Sq11/eksVDdg/Dil5PV2HHpkV8afm/XOY0okSjaUmOkEB5o6OLHCF2+WyZDu4bUVu 4kew7eGVL4kODto5HJzAk/O1InsC0Ms= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1597769213; a=rsa-sha256; cv=none; b=W66sI15Pvrcb/hs8IVGlpQbZZBmRfzNZrrYLbDff5kUiMZSM6Pnnej/wTboPPngZ+np1OW il92cKzZv5zoJzrRNT67nP+dmt/QfrpiE6XHySRKIQaFkcyp68lDgxT2wk7rYSyjlSxY1/ KfGL5LMYZaWdZeedCHcOQeJJVLzp9l0= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: + Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Archived-At: Subject: Re: [GNAP] Support of FIDO 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 16:46:56 -0000 --Apple-Mail-8E24F815-72A2-4385-A573-9375AD112970 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Denis, That text is not in the referenced document? U2F devices do not typically store private keys per site, but instead rely o= n a =E2=80=9Ccredential handle=E2=80=9D presented by the RP which contains a= n encrypted form of the key or keying material used to reserve the key. Some= CTAP2 implementations do store private keys even in U2F compatibility mode,= but these still require presentation of a credential handle.=20 So authentication either can use a CTAP2 authentication with a previously cr= eated credential that is resident/discoverable, or you perform some initial u= ser authentication to determine which credential handles are appropriate to c= hallenge a U2F authenticator with Sent from my iPhone > On Aug 18, 2020, at 10:38 AM, Denis wrote: >=20 > =EF=BB=BF > Hi Tony, >> Not quite Dennis, the U2F device does not store the private key, it only c= reates the private key. > Please read the Client to Authenticator Protocol (CTAP) specification from= the FIDO Alliance: >=20 > https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authen= ticator-protocol-v2.0-ps-20190130.pdf >=20 > Extract: >=20 > (...) the ASPSP (Account Servicing Payment Service Providers) server sen= ds a challenge message to the authenticator > which is then cryptographically signed by a private key stored in the auth= enticator. >=20 > Denis >=20 >> =20 >> From: TXAuth On Behalf Of Denis >> Sent: Friday, August 14, 2020 3:04 AM >> To: nadalin@prodigy.net; txauth@ietf.org >> Subject: Re: [GNAP] Support of FIDO >> =20 >> Hi Tony, >> Dennis, not all the way correct=20 >> It is also possible to get rid of IDs and passwords using FIDO. FIDO disc= loses no private information at all about the user=20 >> and no trust relationships need to be defined since there is no AS >> Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D PII= , there can be all sorts of information passed in ClientData field of the FI= DO response, not desirable but perfectly OK >> None of these two semantics fit with the FIDO use case where the subject v= alue is scoped to be locally unique in the context of one RS.=20 >> Hence, the linkage of users between two RSs (or between one RS and any ot= her server) becomes impossible >> There is nothing that prohibits the RS from sharing registration informat= ion between RS >> I am speaking of FIDO U2F where there are two main phases: registration a= nd authentication. >>=20 >> The U2F device gives the public key and a Key Handle to the origin online= service or website during the user registration step.=20 >> Later, when the user performs an authentication, the origin online servic= e or website sends the Key Handle back to the U2F device=20 >> via the browser. The U2F device uses the Key Handle to identify the user'= s private key, and creates a signature which is sent back=20 >> to the origin to verify the presence of the U2F device. Thus, the Key Han= dle is simply an identifier of a particular key on the U2F device. >>=20 >> There is no other registration information needed. Sharing such an inform= ation between RSs does not allow to link user accounts. >>=20 >> Denis >>=20 >> =20 >> From: TXAuth On Behalf Of Denis >> Sent: Thursday, August 13, 2020 10:31 AM >> To: txauth@ietf.org >> Subject: [GNAP] Support of FIDO >> =20 >> This topic has already been tackled on the list, but I open a new thread f= or it. >>=20 >> In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since= the solution in OAuth 2.0 was to use access tokens,=20 >> there have been used everywhere, even when they were not strictly needed.= =20 >>=20 >>=20 >> It is also possible to get rid of IDs and passwords using FIDO. FIDO disc= loses no private information at all about the user=20 >> and no trust relationships need to be defined since there is no AS.=20 >>=20 >>=20 >> FIDO should be one allowed possibility for the user authentication. In th= e case of FIDO, the user is authenticated under a pseudonym=20 >> specific to the RS. It may observed that there is no equivalent in OAuth b= ecause of the two different semantics of the subject claim. >>=20 >>=20 >> RFC 7519 states: >> The "sub" (subject) claim identifies the principal that is the subject of= the JWT. The claims in a JWT are normally statements about the subject. =20= >> The subject value MUST either be scoped to be locally unique in the conte= xt of the issuer or be globally unique. >> In one case, it is possible to link the subject claim of two users betwee= n two RSs (i.e. using a locally unique identifier in the context of the issu= er)=20 >> while in the other case (i.e. using a globally unique identifier) it is p= ossible, in addition, to link the subject claim between one RS and any other= server=20 >> (i.e. not supporting OAuth) that is using the same globally unique identi= fier. >>=20 >>=20 >> None of these two semantics fit with the FIDO use case where the subject v= alue is scoped to be locally unique in the context of one RS.=20 >>=20 >> Hence, the linkage of users between two RSs (or between one RS and any ot= her server) becomes impossible.=20 >>=20 >>=20 >> There are cases where a user would like to enjoy the unlinkeability prope= rties of FIDO which cannot be met using the claims currently defined in OAut= h. >>=20 >>=20 >> Denis >> =20 >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-8E24F815-72A2-4385-A573-9375AD112970 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Denis,

      That text is not i= n the referenced document?

      U2F devices do not typic= ally store private keys per site, but instead rely on a =E2=80=9Ccredential h= andle=E2=80=9D presented by the RP which contains an encrypted form of the k= ey or keying material used to reserve the key. Some CTAP2 implementations do= store private keys even in U2F compatibility mode, but these still require p= resentation of a credential handle. 

      So authen= tication either can use a CTAP2 authentication with a previously created cre= dential that is resident/discoverable, or you perform some initial user auth= entication to determine which credential handles are appropriate to challeng= e a U2F authenticator with

      Sent from my iPhone
      On Aug 18, 2020, at 10:38 A= M, Denis <denis.ietf@free.fr> wrote:

      =EF=BB=BF =20 =20 =20
      Hi Tony,

      Not quite Dennis, the U2F device does not store the private key, it only creates the private key.

      Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:

      https://fidoalliance.org/s= pecs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-201= 90130.pdf

      Extract:

       (...) the ASPSP  (Account Servicing= Payment Service Providers) server sends a challenge message to the authenticator
      which is then cryptographically signed by a private key stored in the authenticator.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis Sent: Friday, August 14, 2020 3:04 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO

       

      Hi Tony,

      Dennis, not all the way correct

      • It= is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
        and no trust relationships need to be defined since there is no AS

      Depends on if you only consider =E2=80=9Cpr= ivate information=E2=80=9D PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

      • No= ne of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
        Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible         =

      There is nothing that prohibits the RS from sharing registration information between RS

      =

      I am speaking of FIDO U2F where there are two main phases: registration and authentication.

      The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
      Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
      via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back
      to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

      There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org= > On Behalf Of Denis
      Sent: Thursday, August 13, 2020 10:31 AM
      To: txauth@ietf.org
      Subject: [GNAP] Support of FIDO

       

      T= his topic has already been tackled on the list, but I open a new thread for it.

      In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
      there have been used everywhere, even when they were not strictly needed.


      I= t is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
      and no trust relationships need to be defined since there is no AS.


      FI= DO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
      specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.


      R= FC 7519 states:

      The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
      The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

      I= n one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
      while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
      (i.e. not supporting OAuth) that is using the same globally unique identifier.


      N= one of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

      Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.


      T= here are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.


      D= enis

       


      =20 --
      TXAuth mailing list
      TXAuth@ietf.or= g
      https://www.ietf.org/mailman/listinfo/txauth
      = --Apple-Mail-8E24F815-72A2-4385-A573-9375AD112970-- From nobody Tue Aug 18 10:29:38 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 4D4013A0844 for ; Tue, 18 Aug 2020 10:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 w02sOi84Kzlv for ; Tue, 18 Aug 2020 10:29:32 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB413A083B for ; Tue, 18 Aug 2020 10:29:31 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d24 with ME id H5VV230072bcEcA035VVJ2; Tue, 18 Aug 2020 19:29:29 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 18 Aug 2020 19:29:29 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt References: From: Denis Cc: txauth@ietf.org Message-ID: Date: Tue, 18 Aug 2020 19:29:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------58CD6EB9B0F6F59DE3501D99" Content-Language: en-GB 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:29:36 -0000 This is a multi-part message in MIME format. --------------58CD6EB9B0F6F59DE3501D99 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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-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 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 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 > 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) > > o may want access to resources at a Resource Server > o may be interacting with a User and want identity claims about > the User > o requests the Grant Service to grant resource access and > identity claims > * > > *Grant Server* (GS) > > o accepts Grant requests from the GC for resource access and > identity claims > o negotiates the interaction mode with the GC if interaction is > required with the User > o acquires authorization from the User before granting identity > claims to the GC > o acquires authorization from the RO before granting resource > access to the GC > o grants resource access and identity claims to the GC > * > > *Resource Server* (RS) > > o has resources that the GC may want to access > o expresses what the GC must obtain from the GS for access > through documentation or an API. This is not in scope for this > document > o verifies the GS granted access to the GC, when the GS makes > resource access requests > > *Humans* > > * > > *User* > > o the person interacting with the Grant Client. > o has delegated access to identity claims about themselves to > the Grant Server. > o may authenticate at the GS.. > * > > *Resource Owner* (RO) > > o the legal entity that owns resources at the Resource Server (RS). > o has delegated resource access management to the GS. > o 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. > > > > --------------58CD6EB9B0F6F59DE3501D99 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      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-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 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 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

      Hello

      I just pushed an updated version of XAuth:


      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.




      --------------58CD6EB9B0F6F59DE3501D99-- From nobody Tue Aug 18 10:35:46 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 A39E23A088A for ; Tue, 18 Aug 2020 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=prodigy.net 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 2cAi72Rfk2ti for ; Tue, 18 Aug 2020 10:35:42 -0700 (PDT) Received: from sonic305-5.consmr.mail.bf2.yahoo.com (sonic305-5.consmr.mail.bf2.yahoo.com [74.6.133.44]) (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 43DAD3A0885 for ; Tue, 18 Aug 2020 10:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1597772141; bh=8/OR34fNVkt8rClqkT8pDAl9aRfX6MgjlvQX5AyuTBA=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=CGYfbchjU5vao3GkyO2q+oUv1/6nRCXs2zZKYSap8xvCIa3rTfSKuFzsflj+7Mt8UfODCBu7dKQzs6kEdVR3AXEvQhm0TJlUNrinWajhWAs0xjok/1alMiMK9Yj+q9kRCETokfYrdQMgiUzeVw3meIhzW1fJTxlHlKr32Fl8kNWy1RNOnB71dFECeebT9g3h8p+IlQk+nbqIGepNuzDq4id0W4x4Uk2OmVLdhSRD3JH1Yz8xtMqWGXCqFFUoiP679VbHASxk8Lgl2smsiwRNl00otijqljXZ4D+N4yqJPHex+fxy0JiWXI+5qss/j8Eqb2+8zHUdm0TMqUN/3xp/rg== X-YMail-OSG: 401wYhkVM1k.s0X9rq3zRq8i5_qNxt0mh1WgW7NYn7UdFkklS8bWOjyu9vXsb1h sHq9LCDIV.N8PeKzkQ3.WQf_r6xqM_wm7iydqkMx_z9zrh9B_ISgR4tfffp.o_qEtix54vQ0eQlR mEiC5t2ehYvWSgkMkRBWRMzVPmZ.xIFd9_D5FgEo9OluCykaqngvbNHtGkJ2Kp68DbUwdPS1A4CK TmbbKtsL9HLycopwHK4mUPqd1AVaWmGAW49_A51SIo0crr32fT__J4eICSRuPImZ7xOkwQ1aE10k GLisy.Vk60podeTfeoyHXO7zHFknD_ESvOmoaiaffRpaRAdnG3Xh7CQJnB15pCiIkL10GDu_Tkyc smjKrmoP3PBkmge2ukqhc4m6VQN7pvDqPbBeuWxtHfWCY9CRtHDm5RJTK8.ep7xoSzUQLEFtFGoP NZCz3WVM.jhA.D73C2KiR94TmAZE2seMKVyb9ReMpy9lfQSpvKrx7nKBFMq1gSatf5FsVl2tW1Ou TqY3Z9leaN5_MnVd6twmM7eQCbPnREk0It162rVziVguvunclDu3D7GZfrUhGRPsQmEdDI7zdujT tlha55NYWkl9WdwXWUC02NszuTCXesIBTp9DrPAIY5G9HwWCzuy78iMGTrGo5Hk3xgOvl_A518eX 2VGqMWK5a7.r4Srlp87E12B6udQB.hUcJWYtjPZ04gxOPJvF7ib1hvZLG2y1pglQNT7Ljtat.jf9 aQNBp0fadVxQehCRjouEoPDTpXVZe.o5iHQDZjtbZP4.lR1.Z1WqfcfDadtSCTGUFA6NExPDNENE qbl81ICX1GhLyRRzal5MmlLtKEhRYjIQRyLzwXQMZ2bJI1DJp9A7R.86sI_VqXxtCzK5gcE8Dk9_ 8tB23fI7ii5_Gbbp65fieM32z.qj29y1AAK62ESJ1XgRL83lXIsX2hSSwG1zFFD_Ee1BhY5V0IP3 Z7HFR_MKddyS9dn4ACEytnhGgaDEgxWu07ZajV5W_uZXuYSrU.nZOqnmp38fy.Jinb7MCm2LwsHN 43WgbdpNoTF1DEsJkQNeDzNye8yOs0dAQnKFfkyl3YuD5mcD9oYzEW4rEgi.9W3rzojxyp_ZKcC7 QnQOn1EtSkZD9jTsvrHAuFnXFkhT8zx5WbGDLZtnRao1qe4Q4MnjiuXhecnBRnuaiH0MdRpX.8dT lqHpoPGLBlc1jD5KBNMLWVeEJi7aJW7JRC0uRpn6qjt7N.iyi1ySecUo.cBgWj3U1eiC4VWzQ8KA c.IPZoti7wFKMfCgTaYGfQ1eZhW_jZAaIPc8zYBnJJ1NTNUeQO7jLBJf1lZoL9f9lwaNOJui1E7b tBSwOJzdMZhEKxwJdWHkn44qk7Co_cVhodB28IVEI5WKg7.8tCxsJBgxTTPstxcEUcYX89cTJ9EW 4.mfMmhU0biR0cIe5ZgSflyIb9mg6XJFk5YUS0H5ymPg7luKew.6YkSnq420X6Qzo5SzbftWJ0Fa ldGdhcBw9EpV5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Tue, 18 Aug 2020 17:35:41 +0000 Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 546e3b06c5e933f6520ea57bf7c435b4; Tue, 18 Aug 2020 17:35:38 +0000 (UTC) From: To: "'Denis'" , References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> <015801d67245$933b3850$b9b1a8f0$@prodigy.net> <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> In-Reply-To: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> Date: Tue, 18 Aug 2020 10:35:36 -0700 Message-ID: <01fd01d67585$fca832f0$f5f898d0$@prodigy.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01D6754B.504BCBF0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGyCNFpb0eEQXGiQz1xPVxTFZ4nrAJA1Hv+AlIHM6cBpyrj7gJulDD3qUG05OA= Archived-At: Subject: Re: [GNAP] Support of FIDO 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:35:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01FE_01D6754B.504BCBF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable U2F is not CTAP2 or FIDO2, U2F device usually do not store the = cryptographic material on the device as the device has limited = capabilities=20 =20 From: Denis =20 Sent: Tuesday, August 18, 2020 9:37 AM To: nadalin@prodigy.net; txauth@ietf.org Subject: Re: [GNAP] Support of FIDO =20 Hi Tony, Not quite Dennis, the U2F device does not store the private key, it only = creates the private key. Please read the Client to Authenticator Protocol (CTAP) specification = from the FIDO Alliance: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authe= nticator-protocol-v2.0-ps-20190130.pdf Extract: (...) the ASPSP (Account Servicing Payment Service Providers) server = sends a challenge message to the authenticator which is then cryptographically signed by a private key stored in the = authenticator. Denis =20 From: TXAuth = On Behalf Of Denis Sent: Friday, August 14, 2020 3:04 AM To: nadalin@prodigy.net ; txauth@ietf.org = =20 Subject: Re: [GNAP] Support of FIDO =20 Hi Tony,=20 Dennis, not all the way correct=20 1. It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D = PII, there can be all sorts of information passed in ClientData field of = the FIDO response, not desirable but perfectly OK=20 2. None of these two semantics fit with the FIDO use case where the = subject value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible=20 There is nothing that prohibits the RS from sharing registration = information between RS=20 I am speaking of FIDO U2F where there are two main phases: registration = and authentication. The U2F device gives the public key and a Key Handle to the origin = online service or website during the user registration step.=20 Later, when the user performs an authentication, the origin online = service or website sends the Key Handle back to the U2F device=20 via the browser. The U2F device uses the Key Handle to identify the = user's private key, and creates a signature which is sent back=20 to the origin to verify the presence of the U2F device. Thus, the Key = Handle is simply an identifier of a particular key on the U2F device. There is no other registration information needed. Sharing such an = information between RSs does not allow to link user accounts. Denis =20 From: TXAuth = On Behalf Of Denis Sent: Thursday, August 13, 2020 10:31 AM To: txauth@ietf.org =20 Subject: [GNAP] Support of FIDO =20 This topic has already been tackled on the list, but I open a new thread = for it. In OAuth 2.0, one of the goals was to get rid of IDs and passwords. = Since the solution in OAuth 2.0 was to use access tokens,=20 there have been used everywhere, even when they were not strictly = needed.=20 It is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user=20 and no trust relationships need to be defined since there is no AS.=20 FIDO should be one allowed possibility for the user authentication. In = the case of FIDO, the user is authenticated under a pseudonym=20 specific to the RS. It may observed that there is no equivalent in OAuth = because of the two different semantics of the subject claim. RFC 7519 states: The "sub" (subject) claim identifies the principal that is the subject = of the JWT. The claims in a JWT are normally statements about the = subject. =20 The subject value MUST either be scoped to be locally unique in the = context of the issuer or be globally unique. In one case, it is possible to link the subject claim of two users = between two RSs (i.e. using a locally unique identifier in the context = of the issuer)=20 while in the other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server=20 (i.e. not supporting OAuth) that is using the same globally unique = identifier. None of these two semantics fit with the FIDO use case where the subject = value is scoped to be locally unique in the context of one RS.=20 Hence, the linkage of users between two RSs (or between one RS and any = other server) becomes impossible.=20 There are cases where a user would like to enjoy the unlinkeability = properties of FIDO which cannot be met using the claims currently = defined in OAuth. Denis =20 =20 ------=_NextPart_000_01FE_01D6754B.504BCBF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

      U2F is not = CTAP2 or FIDO2, U2F device usually do not store the cryptographic = material on the device as the device has limited capabilities =

       

      From: Denis = <denis.ietf@free.fr>
      Sent: Tuesday, August 18, 2020 = 9:37 AM
      To: nadalin@prodigy.net; = txauth@ietf.org
      Subject: Re: [GNAP] Support of = FIDO

       

      Hi = Tony,

      Not quite Dennis, the U2F = device does not store the private key, it only creates the private = key.

      Please read the Client to = Authenticator Protocol (CTAP) specification from the FIDO = Alliance:

      https://fidoalliance.org/= specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps= -20190130.pdf

      Extract:

       (...) the ASPSP  = (Account Servicing Payment Service Providers) server sends a challenge = message to the authenticator
      which is then cryptographically signed = by a private key stored in the = authenticator.

      Denis

       <= /o:p>

       <= /o:p>

      Hi Tony, =

      Dennis, not = all the way correct

      1. It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
        and no trust relationships need to be defined = since there is no AS

      Depends on = if you only consider =E2=80=9Cprivate information=E2=80=9D PII, there = can be all sorts of information passed in ClientData field of the FIDO = response, not desirable but perfectly OK

      1. None of these two = semantics fit with the FIDO use case where the subject value is scoped = to be locally unique in the context of one RS.
        Hence, the linkage of = users between two RSs (or between one RS and any other server) becomes = impossible

      There is = nothing that prohibits the RS from sharing registration information = between RS

      I am speaking of FIDO U2F where = there are two main phases: registration and = authentication.

      The U2F device gives the public = key and a Key Handle to the origin online service or website during the = user registration step.
      Later, when the user performs an = authentication, the origin online service or website sends the Key = Handle back to the U2F device
      via the browser. The U2F device uses = the Key Handle to identify the user's private key, and creates a = signature which is sent back
      to the origin to verify the presence of = the U2F device. Thus, the Key Handle is simply an identifier of a = particular key on the U2F = device.

      There is no other registration = information needed. Sharing such an information between RSs does not = allow to link user accounts.

      Denis

       <= /o:p>

       <= /o:p>

      This topic has already been = tackled on the list, but I open a new thread for it.

      In OAuth = 2.0, one of the goals was to get rid of IDs and passwords. Since the = solution in OAuth 2.0 was to use access tokens,
      there have been used = everywhere, even when they were not strictly needed. =



      It is also possible to get rid = of IDs and passwords using FIDO. FIDO discloses no private information = at all about the user
      and no trust relationships need to be defined = since there is no AS.



      FIDO should be one allowed = possibility for the user authentication. In the case of FIDO, the user = is authenticated under a pseudonym
      specific to the RS. It may = observed that there is no equivalent in OAuth because of the two = different semantics of the subject = claim.



      RFC 7519 = states:

      The "sub" (subject) = claim identifies the principal that is the subject of the JWT.  The = claims in a JWT are normally statements about the subject. 
      The = subject value MUST either be scoped to be locally unique in the context = of the issuer or be globally = unique.

      In one case, it is possible to = link the subject claim of two users between two RSs (i.e. using a = locally unique identifier in the context of the issuer)
      while in the = other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server
      (i.e. not supporting OAuth) that is using the same = globally unique identifier.



      None of these two semantics fit = with the FIDO use case where the subject value is scoped to be locally = unique in the context of one RS.

      Hence, the linkage of users = between two RSs (or between one RS and any other server) becomes = impossible.



      There are cases where a user = would like to enjoy the unlinkeability properties of FIDO which cannot = be met using the claims currently defined in = OAuth.



      Denis

       

       

      ------=_NextPart_000_01FE_01D6754B.504BCBF0-- 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-- From nobody Tue Aug 18 12:46:19 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 A35153A0B13 for ; Tue, 18 Aug 2020 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UTALFSb-YUWz for ; Tue, 18 Aug 2020 12:46:13 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53EB3A0A74 for ; Tue, 18 Aug 2020 12:46:12 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d86 with ME id H7m8230022bcEcA037m8Ft; Tue, 18 Aug 2020 21:46:10 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 18 Aug 2020 21:46:10 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: GNAP Mailing List References: From: Denis Message-ID: <27879318-fde2-85e4-fd9b-67da34b8be43@free.fr> Date: Tue, 18 Aug 2020 21:46:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------43E8E3E4E028B988AF7D2E5A" Content-Language: en-GB 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 19:46:18 -0000 This is a multi-part message in MIME format. --------------43E8E3E4E028B988AF7D2E5A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > 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.  I don't believe so.  The charter states: "It will *expand *upon the uses cases currently supported by OAuth 2.0 and OpenID Connect ..." The charter also states: "This group is not chartered to develop extensions to OAuth 2.0, and as such *will focus on new technological solutions ** **not necessarily compatible with OAuth 2.0*". We are not necessarily going to support all the current OAuth 2.0 uses cases, since such use cases can already be supported using OAuth 2.0. Denis > ᐧ > > 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-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 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 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 > >> 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) >> >> o may want access to resources at a Resource Server >> o may be interacting with a User and want identity claims >> about the User >> o requests the Grant Service to grant resource access and >> identity claims >> * >> >> *Grant Server* (GS) >> >> o accepts Grant requests from the GC for resource access >> and identity claims >> o negotiates the interaction mode with the GC if >> interaction is required with the User >> o acquires authorization from the User before granting >> identity claims to the GC >> o acquires authorization from the RO before granting >> resource access to the GC >> o grants resource access and identity claims to the GC >> * >> >> *Resource Server* (RS) >> >> o has resources that the GC may want to access >> o expresses what the GC must obtain from the GS for access >> through documentation or an API. This is not in scope for >> this document >> o verifies the GS granted access to the GC, when the GS >> makes resource access requests >> >> *Humans* >> >> * >> >> *User* >> >> o the person interacting with the Grant Client. >> o has delegated access to identity claims about themselves >> to the Grant Server. >> o may authenticate at the GS.. >> * >> >> *Resource Owner* (RO) >> >> o the legal entity that owns resources at the Resource >> Server (RS). >> o has delegated resource access management to the GS. >> o 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 > --------------43E8E3E4E028B988AF7D2E5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Dick,
      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.

       I don't believe so.  The charter states: "It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect ..."

      The charter also states: "This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions
      not necessarily compatible with OAuth 2.0".

      We are not necessarily going to support all the current OAuth 2.0 uses cases, since such use cases can already be supported using OAuth 2.0.

      Denis

      ᐧ

      On Tue, Aug 18, 2020 at 10:29 AM Denis <denis.ietf@free.fr> 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"

      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 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

      Hello

      I just pushed an updated version of XAuth:


      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


      --------------43E8E3E4E028B988AF7D2E5A-- From nobody Tue Aug 18 12:57:57 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 3F2B13A09EC for ; Tue, 18 Aug 2020 12:57:55 -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 ewab0I1z2RGc for ; Tue, 18 Aug 2020 12:57:52 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 C46223A09C7 for ; Tue, 18 Aug 2020 12:57:51 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id b30so10854993lfj.12 for ; Tue, 18 Aug 2020 12:57:51 -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=T64h4FCTUf668Yu1njHlLB4E2K2BC9wA0WCi+Hk/7zw=; b=Uv1aX/ZOZy46tcHg6GsWCYDrsYJJIW0eC/GBdhtyzLIoCEFkCvnSaZTUGevJ3FSCZj xTudInsdmePtMPQMdY2yVS+LQAu5VaihOIq1xzPy2wpyHGjvgo8Qb3iL/uPc+dxvLgGt JRj2LgBsaEaa6rOB2wxfvuB4EAEW0dUGmhTRMszRjcOp7fRhmZmvd8Vupo9vlyXIZcA4 eodMnogndUhxwRPevG7UYfFaNVYs92Vdaqpe6DmdiSudU34VJ5mAJx2q4d0qwOB95m+x WIzxpDq7aYadSXtOCqJpdlOOM+/QB0poIqwAGr0Vta78vIvYdlqP6v9u1Eec8V6Rc+hp Qhig== 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=T64h4FCTUf668Yu1njHlLB4E2K2BC9wA0WCi+Hk/7zw=; b=ZPevApSMNByizez21Z6L3DR5eYedAtq2gFgsgWIsSYnXdZ4f+YuSQ7V1fGabXfXNFa GE9LUSMiU6pspuaYweNOtFswjnLODRqXotKxn28H3NbM74MAV+yMUf8D+qFCxO7ob4H+ DT0+WMOWHR9KWgm+EDEY0xAUPAFIR+BhkPJYgVii0mSM2b1A6n8rZDUyuledq2fGLeSk /EfGcuhv+271xLZEwByhxUC242Pkj56kFDdySk+w77IM24/eCuJufhtMWM8mxGII4rXh HbOERXfXrVJh1OBjXHNsX+0nG9xYSAxJ10MLlxndWtx77H3AiZB0xQpO/WrK0Oar/uAR iCIQ== X-Gm-Message-State: AOAM530OYn5JUIWYbrf9EFXgAu29oYg/kX0lKkmF/WrtrrfXTg6nxnD/ /8PjhsnhDaRJt6GlLW/WCsSkX00v9YPqT/ThxcY= X-Google-Smtp-Source: ABdhPJwLCMYXIWJfoqxloXSbp0GK5YVY0FPNNnQiwq1zHapovtZEolsZ6+zvl+HbB9MaOjd2DeRWAwTvmKYeRhgW8lo= X-Received: by 2002:a19:8044:: with SMTP id b65mr10414123lfd.91.1597780669546; Tue, 18 Aug 2020 12:57:49 -0700 (PDT) MIME-Version: 1.0 References: <27879318-fde2-85e4-fd9b-67da34b8be43@free.fr> In-Reply-To: <27879318-fde2-85e4-fd9b-67da34b8be43@free.fr> From: Dick Hardt Date: Tue, 18 Aug 2020 12:57:12 -0700 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000003cc54105ad2c4db6" 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 19:57:55 -0000 --0000000000003cc54105ad2c4db6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I disagree with your interpretation of the charter -- I'll give you another example. One of my use cases is for the GC to retrieve Claims directly from the GS. There is no RS, so querying an RS first does not make sense. =E1=90=A7 On Tue, Aug 18, 2020 at 12:46 PM Denis wrote: > Hi Dick, > > 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. > > I don't believe so. The charter states: "It will *expand *upon the uses > cases currently supported by OAuth 2.0 and OpenID Connect ..." > > The charter also states: "This group is not chartered to develop > extensions to OAuth 2.0, and as such *will focus on new technological > solutions * > *not necessarily compatible with OAuth 2.0*". > > We are not necessarily going to support all the current OAuth 2.0 uses > cases, since such use cases can already be supported using OAuth 2.0. > > Denis > > =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 i= s >> 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 th= e >> 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-Inte= rnet-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 >> 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 >> >> 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 document= s >> 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. Standar= ds >> 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 deploy= ed >> use cases, offers numerous extension points, and addresses many of the >> security issues in OAuth 2.0 by passing parameters securely between part= ies >> 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 an= d >> Grant Server negotiate the Grant. The Grant Server acquires authorizatio= n >> to grant the Grant to the Grant Client. The Grant Server then returns th= e >> 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 request= ed >> identity claims, and the requested resource access. Extensions may defin= e >> 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. On= e >> 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 grante= d >> 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 th= e >> 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 grante= d >> 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 t= he >> 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 t= o >> 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 authent= icate >> 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 p= air 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 wit= h 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 reques= ts. >> - *Interaction* - how the GC directs the User to interact with the >> GS. This document defines the interaction modes: "redirect", "indirec= t", >> 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 Ac= cess >> URI is used to refresh an access token. >> >> >> >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000003cc54105ad2c4db6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      While I disagree with your interpretation of the charter -= - I'll=C2=A0give you another example.

      One of my= use cases is for the GC to retrieve Claims directly from the GS. There is = no RS, so querying an RS first does not make sense.


      3D""= =E1=90=A7

      On Tue, Aug 18, 2020 at = 12:46 PM Denis <denis.ietf@free.fr= > wrote:
      =20 =20 =20
      Hi Dick,
      =20
      Hi Denis

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

      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.

      =C2=A0I don't believe so.=C2=A0 The chart= er states: "It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect ..."

      The charter also states: "This group is = not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions
      not necessarily compatible with OAuth 2.0".       =

      We are not necessarily going to support all the current OAuth 2.0 uses cases, since such use cases can already be supported using OAuth 2.0.

      Denis

      3D""==E1=90=A7

      On Tue, Aug 18, 2020 at 10:29 AM Denis <denis.ietf@free.fr> 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"

      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 &qu= ot;Grant Client" since it is ambiguous as it does not make any difference between what I call
      a "User Client" and an "Enterprise Client&qu= ot;.

      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 G= S 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

      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 objec= ts 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

      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_Advanced]=C2=A0and JOSE Authentication=C2=A0[JOSE_Authentication]=C2=A0that describes the JOSE mechanisms for client authentication.

      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=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 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=A0= 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 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:

      • 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.=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

      • RFC6749]= =C2=A0Section 1.4.. An GC uses an access token for resource access at a RS.
      • OIDC= ]=C2=A0Section 5. Claims are issued by a Claims Issuer.
      • RFC6749]=C2=A0Section 2.2.
      • OIDC]=C2=A0Section 2. ID Tokens are issued by the GS. The GC uses an ID Token to authenticate the User.
      • RFC7519]=C2=A0Section 2.
      • New Terms


      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --0000000000003cc54105ad2c4db6-- From nobody Tue Aug 18 13:46:30 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 9DC2E3A0C1B for ; Tue, 18 Aug 2020 13:46:28 -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 7JR3J2DSN-ua for ; Tue, 18 Aug 2020 13:46:23 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 8D0CE3A0C20 for ; Tue, 18 Aug 2020 13:46:22 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id r4so19450582wrx.9 for ; Tue, 18 Aug 2020 13:46:22 -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=EXpb12nYbx1ymCSJjGDDEtxcrUCJxT7No8Rp5upJiIg=; b=MDR9YgpUTqs4dgyEq0Z6tBAcIugnSmLYsI1mgaysRucg3GUWs7JnHX6RTbd8FR91yf IaeTTGCkONlyNb47fHACFaW1Sng6rSoY5FbzvyW9AnbAt8Q9ZN34SNsS9Mlo8vDZRwiw agDmyic2Ua1shyQd6Lwg+MiSGWKMn0WaCLPzA= 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=EXpb12nYbx1ymCSJjGDDEtxcrUCJxT7No8Rp5upJiIg=; b=glQOiBURlXvvgGSdvxOFFrKXj5gk0gN9fjJ25NWbSHRbp5MCKjKB93zIAuweFQjQiF Xa8RfiSCUXAIReZ1JeSZ8gRtehljSh4XYzHqPpBaMl+FeMd0uAtX6WrhXjYrzGn1Vrpj rZR3Cj+gU4xGF8P0Ct/xbJ6AZgiJhu4pzGAQ7iRfEhhRfFY/ky/7lRBzfC3q28ixrblq 2G/Wi2GeugKRD1N6V80bjqUbWCKUYWGrevZyAiougaYOfdRQLP+FaYpWP90ZyKcPFbvw 2u9eyvEZ/E6C4uq/7dVid1CrmU3w9WmUNrldOgoHlsSSh7vPRVacdHQH7LvBTzmn1+hh JjOw== X-Gm-Message-State: AOAM530Cuort5b0zsWfE1iukemeEaMGHG4y6d2dVNqN4EBU6qRbyJhrE Gd5S+R+1fuAOHI7iTeRbeAFoiGB5wu4XB0x6jjnLKg== X-Google-Smtp-Source: ABdhPJwdAc50O2bH2GgCfuNrjdvdiiLjqe2PLvdb20gkghPAA5tHHIu75ojYFUgxB4qVkzD7O9tH4aim2kw9Vh9MNlQ= X-Received: by 2002:adf:cc88:: with SMTP id p8mr886881wrj.70.1597783580432; Tue, 18 Aug 2020 13:46:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Francis Pouatcha Date: Tue, 18 Aug 2020 16:46:08 -0400 Message-ID: To: Fabien Imbault Cc: Dick Hardt , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000bd7b4305ad2cfa22" 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 20:46:29 -0000 --000000000000bd7b4305ad2cfa22 Content-Type: text/plain; charset="UTF-8" Hello Fabien, Thank you for creating the page. I dropped the first SSI use case at: https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity Best regards /Francis On Tue, Aug 18, 2020 at 4:57 AM Fabien Imbault wrote: > Hi Francis, > > To clarify the various interaction modes, I've entered a new use case: > https://github.com/ietf-wg-gnap/general/wiki/Categories-of-interaction > Compared to the other cases, I think the use case "User != RO and > interact_mode = synchronous" is challenging, but SSI could be of great > help. > > I've also entered a SSI use case: > https://github.com/ietf-wg-gnap/general/wiki/SSI-integration (very high > level, more as a reminder for now). > > Fabien > > On Mon, Aug 17, 2020 at 4:02 PM Francis Pouatcha wrote: > >> Hello Fabian, >> >> On Mon, Aug 17, 2020 at 8:17 AM Fabien Imbault >> wrote: >> >>> Hi Francis, >>> >>> Thanks for your comments. Mine are inline (marked with "FI"). I think >>> most of that is clear now (except from the way to make it visible on a >>> diagram). >>> >>> I'd actually like to focus more specifically on the previous exchange: >>> >>> 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. >>> >>> > In most cases, getting the asynchronous consent from the RC (distinct >>> from the end-user) would be an issue (unless the end-user is ok to wait). >>> > Here I guess you're considering the case where you want to >>> interactively ask the RC (distinct from the end-user) to consent, instead >>> of making a policy based decision. >>> >>> A practical scenario where we may encounter a synchronous consent >>> request between distinct end-user/RP and RC: a patient has a medical >>> appointment with a new doctor. >>> The doctor needs to access the medical record of the patient. Here the >>> doctor is the end-user/requestor and the patient is the RC. >>> Since they're already interacting face to face (physically or through >>> video), the patient takes his decision (yes/no for each requested item) as >>> soon as the doctor asks him to provide some information. >>> >>> Is this type of synchronous interaction what you had in mind? >>> >> Yes. There are a lot of such use cases in banking, government, health. >> >>> >>> As for SSI, I think there should be a dedicated use case. >>> >>> Cheers >>> Fabien >>> >>> >>> On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha wrote: >>> >>>> Hello Fabian, inline >>>> >>>> On Mon, Aug 17, 2020 at 6:56 AM Fabien Imbault < >>>> fabien.imbault@gmail.com> 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. >>>> >>>> FI ; yes >>> >>>> >>>>> >>>> >>>>> 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. >>>> >>> >>> FI : yes, although in practice most verified credentials are bundled >>> with some claims about identity. Like I'm a student in a bar, I'm going to >>> show the proof of age (instead of date of birth) but am still required to >>> show my name too (or a picture, or whatever that proves I didn't get a >>> proof which belongs to someone else). >>> >> RP-AS will verify RP identity and produce different RP-identifiers for >> each grant negotiation use case [GC,RS,GS], thereby preservice RP privacy >> and preventing correlations. >> >> >>> >>>> >>>> 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] >>>> >>> >>> FI : this type of interaction with SSI wallets directly on the mobile >>> device would be interesting to dig into. If it hasn't been done yet, we >>> should add a use case. >>> >> Yes... >> >> >>>> >>>>> 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. >>>> >>> >>> FI : problem is that if you show that, most people will assume it's >>> mandatory (as least for the alt2 part). At least I think that's what most >>> readers would assume from reading the schema. >>> >> Therefore it is essential to have Dick introduce the section 1.3 with the >> notion that this is an abstract model that might take a different concrete >> form for each problem domain (resp. trust model) >> >> errata: Above i meant [RP-AS will also reside on a user device] and not >> [RP-RC]. >> /Francis >> >>> >>> >>>> 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. >>>> >>> >>> FI : see discussion at the start of the message >>> >>>> >>>> >>>>> 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. >>>> >>> >>> FI : yes. >>> >>>> >>>> >>>>> 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? >>>> >>> >>> FI : let me think about it ;-) >>> >>> >>>> >>>> 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/ >>>> >>> >> >> -- >> 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/ --000000000000bd7b4305ad2cfa22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hello Fabien,


      Best reg= ards
      /Francis

      On Tue, Aug 18, 2020 at 4:57 AM Fabien Imbaul= t <fabien.imbault@gmail.com<= /a>> wrote:
      <= div dir=3D"ltr">Hi Francis,=C2=A0

      Compared to the other cases, I think the use case "= User !=3D RO and interact_mode =3D synchronous" is challenging, but SS= I could be of great help.=C2=A0

      I've also = entered a SSI use case:=C2=A0https://github.com/ietf-wg-gna= p/general/wiki/SSI-integration=C2=A0(very high level, more as a reminde= r for now).=C2=A0

      Fabien

      On Mon, Aug 17, 2020 at 4:02 PM Francis Pouatcha <fpo@adorsys.de> wrote:
      Hello Fabian,

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

      Thanks for your comments. Mine are inline (marked with "FI"). I = think most of that is clear now (except from the way to make it visible on = a diagram).

      I'd actually like to focus more sp= ecifically on the previous exchange:

      Are we sure we n= eed 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 adva= ntage (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.

      > In most cases, getting the asynchronous=C2=A0consent from the RC (dis= tinct from the end-user) would be an issue (unless the end-user is ok to wa= it).
      > Here I guess you're considering th= e case where you want to interactively ask the RC (distinct from the end-us= er) to consent, instead of making a policy based decision.=C2=A0
      =
      A practical scenario where we may encounter a synchronous co= nsent request between distinct end-user/RP and RC: a patient has a medical = appointment with a new doctor.
      The doctor needs to access the med= ical record of the patient. Here the doctor is the end-user/requestor and t= he patient is the RC.
      Since they're already interacting face = to face (physically or through video), the patient takes his decision (yes/= no for each requested item) as soon as the doctor asks him to provide some = information.=C2=A0

      Is this type of synchronous int= eraction what you had in mind?
      Yes. Ther= e are a lot of such use cases in banking, government, health.=C2=A0

      As for SSI, I think there should be a dedicate= d use case.=C2=A0

      Cheers
      Fabi= en


      On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha <= ;fpo@adorsys.de>= wrote:
      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 discussions we had p= reviously (on privacy and other topics) but I think this schema is too pres= criptive.
      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 entity. This m= eans the oAuth2 instantiated model might look very simple.

      FI ; yes=C2=A0
      =C2=A0

      Depending on the situa= tion, 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,=C2=A0[GS]= =3D[RC-AS]=3D[RP-AS]=3DGS resulting=C2=A0 in the original model of Dick.
      =C2=A0
      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=C2=A0original 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.=C2=A0
      In those cases [GS] --(3)-->[GC]++(B)++>[RP] ma= kes sense.

      FI : yes, alth= ough in practice most verified credentials are bundled with some claims abo= ut identity. Like I'm a student in a bar, I'm going to show the pro= of of age (instead of date of birth) but am still required to show my name = too (or a picture, or whatever that proves I didn't get a proof which b= elongs to someone else).
      RP-AS will veri= fy RP identity and produce different RP-identifiers for each grant negotiat= ion use=C2=A0case [GC,RS,GS], thereby preservice RP privacy and preventing = correlations.

      =C2=A0 =C2=A0= =C2=A0

      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]

      FI : this type of interaction with SSI wa= llets directly on the mobile device would be interesting to dig into. If it= hasn't been done yet, we should add a use case.=C2=A0 =C2=A0
      Yes...

      =C2=A0
      Why mandate that interaction C sh= all always occur through a GS? (I'm sure Denis will not want this, for = instance).
      This is not a mandate, but an abstr= act model. In SSI/DID most of the time, RP-RC will also reside on a user de= vice.

      FI : problem is tha= t if you show that, most people will assume it's mandatory (as least fo= r the alt2 part). At least I think that's what most readers would assum= e from reading the schema.
      Therefore it = is essential to have Dick introduce the section 1.3 with the notion that th= is is an abstract model that might take a different concrete form for each = problem domain (resp. trust model)=C2=A0

      errata: A= bove i meant [RP-AS will also reside on a user device] and not [RP-RC].
      /Francis

      <= div>
      Are we sure we need to formally separate B and C? This goes beyo= nd previous discussions of separating the front and back channels, and I do= n'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.

      FI : see discussion at the start = of the message=C2=A0


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

      FI : yes.=C2=A0=C2=A0


      <= div>For instance, an (optional) Interact Server (IS) could provide support = for a decoupled front-channel:=C2=A0
      - it does not change the int= eraction between a GC and a GS. It does change the trust model though, depe= nding 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 spec= ified, the GS decides.=C2=A0
      - the IS is able to handle the front= -channel for idclaims and consent, and return back to the GS what access to= kens are required.
      - notice that although the IS is focused on fr= ont-channel interaction, there are cases where the consent needs to be base= d on policies instead of a direct human interaction (typically when end-use= r is not the RC, and therefore the end-user is not the one that is asked fo= r consent / then of course, if the RC logs in, he would be able to manage h= is consent policies).=C2=A0
      What you mention h= ere is why I display RP-AS and RC-AS!
      =C2=A0
      So ther= e's really no obligation that B occurs through the GC and C occurs thro= ugh the GS. It depends on where your front-channel is located (GC, GS, thir= d-party).
      Yes. I agree with=C2=A0you. How can = we make this=C2=A0 visible in a diagram?

      FI : let me think about it ;-)
      =C2=A0

      This I think makes it a very flexible model, while= 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<= /a>> wrote:
      <= div dir=3D"ltr">Hello Dick,

      <= div>
      Thanks for pointing this out. This is the= new diagram where=C2=A0++++ refers=C2=A0to what Endpoint/Human interaction= 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 | Reques= ting =C2=A0| =C2=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|
      =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 +--->| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 +-->| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
      =C2=A0 =C2=A0 =C2=A0 = =C2=A0 + =C2=A0|=C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 | =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 = + (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=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 Ser= ver =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 k= now what is part of the protocol:
      Alt-1: only (1..6). This is what you specified in section 1.2, and I am fi= ne with that.
      Alt-2: Alt-1=C2=A0+= =C2=A0(B0, C0). This is a result of the discussion we have been having arou= nd privacy, GS as big brother, aso....

      P.S.: an authenticatio= n [RP]+++(A)+++>[GC] can be assumed, but shall be irrelevant for the pro= tocol. [RP]+++(B1)+++>[RP-AS] is important for later instantiation of th= e model. As in many cases, like in oAuth [RP-AS] could be the same entity l= ike [GS].

      /Francis


      <= div class=3D"gmail_quote">
      On Sun, Aug= 16, 2020 at 7:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Francis

      =
      I was intentional in stating 1.3 that it is human interactions. = The connection lines are '+=C2=A0+=C2=A0+' rather than '-----&#= 39; to indicate that it is a human interaction rather than a protocol betwe= en roles. We can't specify how a human interaction works, but we can sh= ow 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 no= t roles in the protocol, but are entities in the trust model.
      I debated keeping the interactions abstract and not 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 represent the author= ization and the consent for the GC to pass to the GS, but the roles and ent= ities stay the same. The trust model does change though.

      /Dick







      On Sun, Aug 16, 2020 at 3:46 PM Francis Po= uatcha <fpo@adorsys.= de> wrote:
      Hello Dick,=C2=A0my feedback below:

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

      1.3:
      Title: Human Int= eraction -> End User Interaction
      I would title this "End User&qu= ot; interaction and not "human ...". It is not about having a hum= an, 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 u= sed by UMA.

      Participant: "Resource Controller". In past di= scussions there was a consensus on using "Resource Controller" in= stead.

      (B) I which the GS never interacts with the "Requesting = Party" in a matter of obtaining a grant to a resource (many reasons: p= rivacy, confidentiality, abstraction, ...). Generally the GS will need info= rmation (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" wi= ll be obtained from another "Authorization Server" (AS). The word= AS is intentionally chosen here. In this same login, the path (C0, C1) bel= ow will not only return the RC consent, but might also return some claims o= n RC.

      ASs provide authentication "of" and consent collecti= on "from" End Users. End users are in this case the Requesting Pa= rty, and the Resource Controller).

      The result can look like the modi= fied diagram below. With this we can address some privacy concerns 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|
      =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|<= br>=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) repl= ace (B). Occur inside step (3), GS asks GC to collect the claims. GC contac= ts RP-AS to negotiate those=C2=A0claims. But it is important to mention tha= t those Claims-RP are not the target Grant being negotiated for the resourc= e access. They are generally=C2=A0used by GS (and later RS) as input into p= erforming authz decisions.

      (C0, C1) replace (C). They occur= =C2=A0after step (3) (Beware of the difference=C2=A0to Bs that occur=C2=A0i= nside 3). This separation address the Big Brother problem we have been disc= ussing in the list.

      Essential is to mention that in an instan= tiation 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 Us= er".=C2=A0

      Off-topic: Th= e splitting of GS and AS was suggested in some discussions on the mailing l= ist. But we have no mean yet to isolate good inputs for later reuse. This i= s 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 neede= d to have a structure for this section.


      1.5
      I suggest again w= e replace Human with "End User" and still make them roles. This i= s:
      Terminology (Are all roles)
      =C2=A0 -> These roles can be borne = by End Users
      =C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)
      =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 fund= amental 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 = <dick.hardt@gm= ail.com> wrote:
      =
      Hello

      I just pushed an updat= ed 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 introdu= ction included below for your convenience

      /Dick

      1.=C2=A0Introduction

      = EDITOR NOTE

      This document captures a numbe= r of concepts that may be adopted by the proposed GNAP working group. Pleas= e refer to this document as:

      XAuth

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

      This d= ocument describes the core Grant Negotiation and Authorization Protocol (GN= AP). The protocol supports the widely deployed use cases supported by OAuth= 2.0=C2=A0[RFC6749]=C2=A0&=C2=A0[R= FC6750], OpenID Connect=C2=A0[OIDC]=C2=A0- a= n extension of OAuth 2.0, as well as other extensions. Related documents in= clude: GNAP - Advanced Features=C2=A0[GNAP_Advanced]<= /span>=C2=A0and JOSE Authentication=C2=A0[JOSE_Aut= hentication]=C2=A0that describes the JOSE mechanisms for client = authentication.

      The technology landscape has changed since OAut= h 2.0 was initially drafted. More interactions happen on mobile devices tha= n PCs. Modern browsers now directly support asymetric cryptographic functio= ns. Standards have emerged for signing and encrypting tokens with rich payl= oads (JOSE) that are widely deployed.

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

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

      The suggested pron= unciation 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 fro= m a Grant Server. The Grant Client and Grant Server negotiate the Grant. Th= e Grant Server acquires authorization to grant the Grant to the Grant Clien= t. The Grant Server then returns the Grant to the Grant Client.

      The Grant Request may contain information about the User, the Grant Cl= ient, the interaction modes supported by the Grant Client, the requested id= entity claims, and the requested resource access. Extensions may define add= itional information to be included in the Grant Request.

      1.2.=C2=A0Protoc= ol 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 r= esource access. This step is not in scope for this document.<= /a>

      S= ection 3.2). How the GC authenticates to the GS is not in scope for thi= s document. One mechanism is=C2=A0[JOSE_Authenticat= ion].

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

      (4) The GS returns a Grant to the GC (Grant Response=C2=A0= Section 4.1).

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

      (6) The R= S 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 Grant Client may be interacting with a human end-user (= User), and the Grant Client may need to get authorization to release the Gr= ant from the User, or from the owner of the resources at the Resource Serve= r, the Resource Owner (RO)

      Below is when the human interact= ions 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

      St= eps (1) - (6) are the same as=C2=A0Section 1.2. The additio= n of the human interactions (A) - (C) are=C2=A0bolded=C2= =A0below.

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

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

      (2) The GC makes a Grant re= quest to the GS

      (3) The GC and GS may negotiate the Grant

      (B) The GS may interact with the User for grant auth= orization

      (C) The GS may interact with th= e 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 determi= ne access granted to the GC

      Alternatively, the Resource O= wner could be a legal entity that has a software component that the Grant S= erver interacts with for Grant authorization. This interaction is not in sc= ope of this document.

      1.4.= =C2=A0Trust Model

      In addition to the User and the Re= source Owner, there are three other entities that are part of the trust mod= el:

        =
      • Cli= ent Owner=C2=A0(CO) - the legal entity that owns the Grant Client.=
      • Grant Server Owner=C2=A0(GSO) - the legal en= tity 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 th= e 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 in= terest with the Grant the GSO grants to the CO

      (C) CO tru= sts claims issued by the GSO

      (D) CO trusts claims issued by= the RO

      (E) RO trusts the GSO to manage access to the RO re= sources

      1.5.=C2=A0Terminology

      Roles

      • Grant Client=C2=A0(GC)

        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 r= esources at the Resource Server (RS).
          • has delegated= resource access management to the GS.
          • may be the U= ser, 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[RFC6749]= =C2=A0Section 1.4.. An GC uses an access token for resource access a= t a RS.
        • Claim=C2=A0- a Claim as defined in=C2= =A0[OIDC]=C2=A0Section 5. Claims are issued by a Claims= Issuer.
        • Client ID=C2=A0- a GS unique identi= fier for a Registered Client as defined in=C2=A0[RFC6749]=C2=A0Section 2.2.
        • ID Token=C2=A0- an I= D Token as defined in=C2=A0[OIDC]=C2=A0Section 2. ID To= kens 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.
        • authN=C2=A0- short = for authentication.
        • authZ=C2=A0- short for au= thorization.

        New Terms

        • GS URI=C2= =A0- the endpoint at the GS the GC calls to create a Grant, and is the uniq= ue identifier for the GS.
        • Registered Client= =C2=A0- a GC that has registered with the GS and has a Client ID to identif= y 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 c= an 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 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 i= n subsequent requests. A single-page application with no active server comp= onent 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.<= /a>
        • Interaction=C2=A0- how the GC directs the User to interact wi= th the GS. This document defines the interaction modes: "redirect"= ;, "indirect", and "user_code" in=C2=A0S= ection 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 G= S URI.
        • Access=C2=A0- the access granted by t= he RO to the GC and contains an access token. The GS may invalidate an Acce= ss at any time.
        • Access URI=C2=A0- the URI tha= t represents the Access the GC was granted by the RO. The Access URI MUST s= tart with the GS URI.. The Access URI is used to refresh an access token.


      <= /div>
      --
      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


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


      --
      Francis Pouatcha
      Co-= Founder and Technical Lead
      adorsys GmbH & Co. KG
      https://= adorsys-platform.de/solutions/
      --000000000000bd7b4305ad2cfa22-- From nobody Wed Aug 19 01:37:13 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 9D5483A1273 for ; Wed, 19 Aug 2020 01:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eNCgbwOHqk5H for ; Wed, 19 Aug 2020 01:37:09 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0A53A1227 for ; Wed, 19 Aug 2020 01:37:08 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id HLd32300C2bcEcA03Ld3sK; Wed, 19 Aug 2020 10:37:06 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 19 Aug 2020 10:37:06 +0200 X-ME-IP: 90.79.51.120 To: David Cc: nadalin@prodigy.net, txauth@ietf.org References: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> <0E8FCF98-F5E7-4C1D-8491-96CFEF7AA3C4@alkaline-solutions.com> From: Denis Message-ID: <9b1b3fa0-9b91-7bb0-2418-2c96518044a8@free.fr> Date: Wed, 19 Aug 2020 10:37:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <0E8FCF98-F5E7-4C1D-8491-96CFEF7AA3C4@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="------------BA710781DB890B6D2C203A06" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Wed, 19 Aug 2020 08:37:12 -0000 This is a multi-part message in MIME format. --------------BA710781DB890B6D2C203A06 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit David, > Denis, > > That text is not in the referenced document? You are right. This sentence is present in that document: https://media.fidoalliance.org/wp-content/uploads/2020/06/PSD2-Support-Why-Change-to-FIDO-White-Paper.pdf > U2F devices do not typically store private keys per site, but instead > rely on a “credential handle” presented by the RP which contains an > encrypted form of the key or keying material used to reserve the key. > Some CTAP2 implementations do store private keys even in U2F > compatibility mode, but these still require presentation of a > credential handle. > > So authentication either can use a CTAP2 authentication with a > previously created credential that is resident/discoverable, or you > perform some initial user authentication to determine which credential > handles are appropriate to challenge a U2F authenticator with Such implementations details are not important for the present discussion. The key question is whether FIDO authentication would be one authentication possibility advertised by the RS and, if so, how the client should be informed of it by the RS. Denis > > Sent from my iPhone > >> On Aug 18, 2020, at 10:38 AM, Denis wrote: >> >>  >> Hi Tony, >>> >>> Not quite Dennis, the U2F device does not store the private key, it >>> only creates the private key. >>> >> Please read the Client to Authenticator Protocol (CTAP) specification >> from the FIDO Alliance: >> >> https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf >> >> Extract: >> >>  (...) the ASPSP  (Account Servicing Payment Service Providers) >> server sends a challenge message to the authenticator >> which is then cryptographically signed by a *private key stored >> in the authenticator.* >> >> Denis >> >>> *From:* TXAuth *On Behalf Of *Denis >>> *Sent:* Friday, August 14, 2020 3:04 AM >>> *To:* nadalin@prodigy.net; txauth@ietf.org >>> *Subject:* Re: [GNAP] Support of FIDO >>> >>> Hi Tony, >>> >>> Dennis, not all the way correct >>> >>> * It is also possible to get rid of IDs and passwords using >>> FIDO. FIDO discloses no private information at all about the >>> user >>> and no trust relationships need to be defined since there is >>> no AS >>> >>> Depends on if you only consider “private information” PII, there >>> can be all sorts of information passed in ClientData field of >>> the FIDO response, not desirable but perfectly OK >>> >>> * None of these two semantics fit with the FIDO use case where >>> the subject value is scoped to be locally unique in the >>> context of one RS. >>> Hence, the linkage of users between two RSs (or between one >>> RS and any other server) becomes impossible >>> >>> There is nothing that prohibits the RS from sharing registration >>> information between RS >>> >>> I am speaking of FIDO U2F where there are two main phases: >>> registration and authentication. >>> >>> The U2F device gives the public key and a Key Handle to the >>> origin online service or website during the user registration step. >>> Later, when the user performs an authentication, the origin >>> online service or website sends the Key Handle back to the U2F >>> device >>> via the browser. The U2F device uses the Key Handle to identify >>> the user's private key, and creates a signature which is sent back >>> to the origin to verify the presence of the U2F device. Thus, >>> the Key Handle is simply an identifier of a particular key on >>> the U2F device. >>> >>> There is no other registration information needed. Sharing such an >>> information between RSs does not allow to link user accounts. >>> >>> Denis >>> >>> *From:* TXAuth >>> *On Behalf Of *Denis >>> *Sent:* Thursday, August 13, 2020 10:31 AM >>> *To:* txauth@ietf.org >>> *Subject:* [GNAP] Support of FIDO >>> >>> This topic has already been tackled on the list, but I open a >>> new thread for it. >>> >>> In OAuth 2.0, one of the goals was to get rid of IDs and >>> passwords. Since the solution in OAuth 2.0 was to use access >>> tokens, >>> there have been used everywhere, even when they were not >>> strictly needed. >>> >>> >>> It is also possible to get rid of IDs and passwords using FIDO. >>> FIDO discloses no private information at all about the user >>> and no trust relationships need to be defined since there is no AS. >>> >>> >>> FIDO should be one allowed possibility for the user >>> authentication. In the case of FIDO, the user is authenticated >>> under a pseudonym >>> specific to the RS. It may observed that there is no equivalent >>> in OAuth because of the two different semantics of the subject >>> claim. >>> >>> >>> RFC 7519 states: >>> >>> The "sub" (subject) claim identifies the principal that is >>> the subject of the JWT.  The claims in a JWT are normally >>> statements about the subject. >>> The subject value MUST either be scoped to be locally unique >>> in the context of the issuer or be globally unique. >>> >>> In one case, it is possible to link the subject claim of two >>> users between two RSs (i.e. using a locally unique identifier in >>> the context of the issuer) >>> while in the other case (i.e. using a globally unique >>> identifier) it is possible, in addition, to link the subject >>> claim between one RS and any other server >>> (i.e. not supporting OAuth) that is using the same globally >>> unique identifier. >>> >>> >>> None of these two semantics fit with the FIDO use case where the >>> subject value is scoped to be locally unique in the context of >>> one RS. >>> >>> Hence, the linkage of users between two RSs (or between one RS >>> and any other server) becomes impossible. >>> >>> >>> There are cases where a user would like to enjoy the >>> unlinkeability properties of FIDO which cannot be met using the >>> claims currently defined in OAuth. >>> >>> >>> Denis >>> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --------------BA710781DB890B6D2C203A06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      David,

      Denis,

      That text is not in the referenced document?

      You are right. This sentence is present in that document:

      https://media.fidoalliance.org/wp-content/uploads/2020/06/PSD2-Support-Why-Change-to-FIDO-White-Paper.pdf

      U2F devices do not typically store private keys per site, but instead rely on a “credential handle” presented by the RP which contains an encrypted form of the key or keying material used to reserve the key. Some CTAP2 implementations do store private keys even in U2F compatibility mode, but these still require presentation of a credential handle. 

      So authentication either can use a CTAP2 authentication with a previously created credential that is resident/discoverable, or you perform some initial user authentication to determine which credential handles are appropriate to challenge a U2F authenticator with

      Such implementations details are not important for the present discussion. The key question is whether FIDO authentication would be one authentication possibility
      advertised by the RS and, if so, how the client should be informed of it by the RS.

      Denis


      Sent from my iPhone

      On Aug 18, 2020, at 10:38 AM, Denis <denis.ietf@free.fr> wrote:

      
      Hi Tony,

      Not quite Dennis, the U2F device does not store the private key, it only creates the private key.

      Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:

      https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf

      Extract:

       (...) the ASPSP  (Account Servicing Payment Service Providers) server sends a challenge message to the authenticator
      which is then cryptographically signed by a private key stored in the authenticator.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Friday, August 14, 2020 3:04 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO

       

      Hi Tony,

      Dennis, not all the way correct

      • It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
        and no trust relationships need to be defined since there is no AS

      Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

      • None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
        Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible

      There is nothing that prohibits the RS from sharing registration information between RS

      I am speaking of FIDO U2F where there are two main phases: registration and authentication.

      The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
      Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
      via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back
      to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

      There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Thursday, August 13, 2020 10:31 AM
      To: txauth@ietf.org
      Subject: [GNAP] Support of FIDO

       

      This topic has already been tackled on the list, but I open a new thread for it.

      In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
      there have been used everywhere, even when they were not strictly needed.


      It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
      and no trust relationships need to be defined since there is no AS.


      FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
      specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.


      RFC 7519 states:

      The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
      The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

      In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
      while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
      (i.e. not supporting OAuth) that is using the same globally unique identifier.


      None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

      Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.


      There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.


      Denis

       


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


      --------------BA710781DB890B6D2C203A06-- From nobody Wed Aug 19 01:39:13 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 4ECE83A12D0 for ; Wed, 19 Aug 2020 01:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7jX6JiBWW7nw for ; Wed, 19 Aug 2020 01:39:10 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E633A12C9 for ; Wed, 19 Aug 2020 01:39:09 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id HLf6230052bcEcA03Lf75c; Wed, 19 Aug 2020 10:39:07 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 19 Aug 2020 10:39:07 +0200 X-ME-IP: 90.79.51.120 To: nadalin@prodigy.net, txauth@ietf.org References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> <015801d67245$933b3850$b9b1a8f0$@prodigy.net> <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> <01fd01d67585$fca832f0$f5f898d0$@prodigy.net> From: Denis Message-ID: <0c2e0e75-808c-2859-3bad-e1b5cadda9ee@free.fr> Date: Wed, 19 Aug 2020 10:39:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <01fd01d67585$fca832f0$f5f898d0$@prodigy.net> Content-Type: multipart/alternative; boundary="------------1B0AB86212F23BDF795558B9" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Wed, 19 Aug 2020 08:39:12 -0000 This is a multi-part message in MIME format. --------------1B0AB86212F23BDF795558B9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tony, Functionally, private keys are stored and used by the authenticator. For capacity limitations, they can be stored elsewhere if both correctly integrity and confidentiality protected. That additional storage is an extension of the limited storage of the authenticator. I was attempting to promote the use of FIDO within this WG. Are you against or in favour of such a possibility ? Denis > U2F is not CTAP2 or FIDO2, U2F device usually do not store the > cryptographic material on the device as the device has limited > capabilities > > *From:* Denis > *Sent:* Tuesday, August 18, 2020 9:37 AM > *To:* nadalin@prodigy.net; txauth@ietf.org > *Subject:* Re: [GNAP] Support of FIDO > > Hi Tony, > > Not quite Dennis, the U2F device does not store the private key, > it only creates the private key. > > Please read the Client to Authenticator Protocol (CTAP) specification > from the FIDO Alliance: > > https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf > > Extract: > >  (...) the ASPSP  (Account Servicing Payment Service Providers) > server sends a challenge message to the authenticator > which is then cryptographically signed by a *private key stored in > the authenticator.* > > Denis > > *From:* TXAuth > *On Behalf Of *Denis > *Sent:* Friday, August 14, 2020 3:04 AM > *To:* nadalin@prodigy.net ; > txauth@ietf.org > *Subject:* Re: [GNAP] Support of FIDO > > Hi Tony, > > Dennis, not all the way correct > > 1. It is also possible to get rid of IDs and passwords using > FIDO. FIDO discloses no private information at all about > the user > and no trust relationships need to be defined since there > is no AS > > Depends on if you only consider “private information” PII, > there can be all sorts of information passed in ClientData > field of the FIDO response, not desirable but perfectly OK > > 2. None of these two semantics fit with the FIDO use case > where the subject value is scoped to be locally unique in > the context of one RS. > Hence, the linkage of users between two RSs (or between > one RS and any other server) becomes impossible > > There is nothing that prohibits the RS from sharing > registration information between RS > > I am speaking of FIDO U2F where there are two main phases: > registration and authentication. > > The U2F device gives the public key and a Key Handle to the > origin online service or website during the user registration > step. > Later, when the user performs an authentication, the origin > online service or website sends the Key Handle back to the U2F > device > via the browser. The U2F device uses the Key Handle to > identify the user's private key, and creates a signature which > is sent back > to the origin to verify the presence of the U2F device. Thus, > the Key Handle is simply an identifier of a particular key on > the U2F device. > > There is no other registration information needed. Sharing such an > information between RSs does not allow to link user accounts. > > Denis > > *From:* TXAuth > *On Behalf Of *Denis > *Sent:* Thursday, August 13, 2020 10:31 AM > *To:* txauth@ietf.org > *Subject:* [GNAP] Support of FIDO > > This topic has already been tackled on the list, but I open a > new thread for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and > passwords. Since the solution in OAuth 2.0 was to use access > tokens, > there have been used everywhere, even when they were not > strictly needed. > > > > It is also possible to get rid of IDs and passwords using > FIDO. FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is > no AS. > > > > FIDO should be one allowed possibility for the user > authentication. In the case of FIDO, the user is authenticated > under a pseudonym > specific to the RS. It may observed that there is no > equivalent in OAuth because of the two different semantics of > the subject claim. > > > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is > the subject of the JWT.  The claims in a JWT are normally > statements about the subject. > The subject value MUST either be scoped to be locally > unique in the context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two > users between two RSs (i.e. using a locally unique identifier > in the context of the issuer) > while in the other case (i.e. using a globally unique > identifier) it is possible, in addition, to link the subject > claim between one RS and any other server > (i.e. not supporting OAuth) that is using the same globally > unique identifier. > > > > None of these two semantics fit with the FIDO use case where > the subject value is scoped to be locally unique in the > context of one RS. > > Hence, the linkage of users between two RSs (or between one RS > and any other server) becomes impossible. > > > > There are cases where a user would like to enjoy the > unlinkeability properties of FIDO which cannot be met using > the claims currently defined in OAuth. > > > > Denis > --------------1B0AB86212F23BDF795558B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Tony,

      Functionally, private keys are stored and used by the authenticator. For capacity limitations, they can be stored elsewhere if both correctly integrity and confidentiality protected.
      That additional storage is an extension of the limited storage of the authenticator.

      I was attempting to promote the use of FIDO within this WG. Are you against or in favour of such a possibility ?

      Denis

      U2F is not CTAP2 or FIDO2, U2F device usually do not store the cryptographic material on the device as the device has limited capabilities

       

      From: Denis <denis.ietf@free.fr>
      Sent: Tuesday, August 18, 2020 9:37 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO

       

      Hi Tony,

      Not quite Dennis, the U2F device does not store the private key, it only creates the private key.

      Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:

      https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.pdf

      Extract:

       (...) the ASPSP  (Account Servicing Payment Service Providers) server sends a challenge message to the authenticator
      which is then cryptographically signed by a private key stored in the authenticator.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Friday, August 14, 2020 3:04 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO

       

      Hi Tony,

      Dennis, not all the way correct

      1. It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
        and no trust relationships need to be defined since there is no AS

      Depends on if you only consider “private information” PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

      1. None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
        Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible

      There is nothing that prohibits the RS from sharing registration information between RS

      I am speaking of FIDO U2F where there are two main phases: registration and authentication.

      The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
      Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
      via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back
      to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

      There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

      Denis

       

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Thursday, August 13, 2020 10:31 AM
      To: txauth@ietf.org
      Subject: [GNAP] Support of FIDO

       

      This topic has already been tackled on the list, but I open a new thread for it.

      In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
      there have been used everywhere, even when they were not strictly needed.



      It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
      and no trust relationships need to be defined since there is no AS.



      FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
      specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.



      RFC 7519 states:

      The "sub" (subject) claim identifies the principal that is the subject of the JWT.  The claims in a JWT are normally statements about the subject. 
      The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

      In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
      while in the other case (i.e. using a globally unique identifier) it is possible, in addition, to link the subject claim between one RS and any other server
      (i.e. not supporting OAuth) that is using the same globally unique identifier.



      None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

      Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.



      There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.



      Denis

       

       


      --------------1B0AB86212F23BDF795558B9-- From nobody Wed Aug 19 01:42:03 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 C877A3A1304 for ; Wed, 19 Aug 2020 01:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SPCaHQ3vooPw for ; Wed, 19 Aug 2020 01:41:56 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A583A1300 for ; Wed, 19 Aug 2020 01:41:54 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id HLhs2300Q2bcEcA03LhsNe; Wed, 19 Aug 2020 10:41:53 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 19 Aug 2020 10:41:53 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: GNAP Mailing List References: <27879318-fde2-85e4-fd9b-67da34b8be43@free.fr> From: Denis Message-ID: <0b2338ea-d7a4-bd9c-f7dc-19ebfa980c70@free.fr> Date: Wed, 19 Aug 2020 10:41:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------72A3B0F0E27804757EF7A67B" Content-Language: en-GB 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: Wed, 19 Aug 2020 08:42:00 -0000 This is a multi-part message in MIME format. --------------72A3B0F0E27804757EF7A67B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > While I disagree with your interpretation of the charter -- I'll give > you another example. > > One of my use cases is for the GC to retrieve Claims directly from the > GS. There is no RS, so querying an RS first does not make sense. So, let us notice this disagreement. I was only discussing the very first exchange from the figure inserted in section 1.2. The use case you mention has nothing to do with section 1.2. Moreover, the example you mention is not described, nor illustrated by any figure in the draft. Nevertheless, the use case you mention is straightforward.  A User should be able to query at any time both the attributes _/and the capabilities,/_ if any, that are registered by the AS. We should define a protocol for this retrieval. BTW, the sentence you are using includes the word "Claims" which is currently left undefined, since Section 5 from [OIDC] does not provide any formal definition for it. Denis > On Tue, Aug 18, 2020 at 12:46 PM Denis > wrote: > > Hi Dick, >> 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. > >  I don't believe so.  The charter states: "It will *expand *upon > the uses cases currently supported by OAuth 2.0 and OpenID Connect > ..." > > The charter also states: "This group is not chartered to develop > extensions to OAuth 2.0, and as such *will focus on new > technological solutions ** > **not necessarily compatible with OAuth 2.0*". > > We are not necessarily going to support all the current OAuth 2.0 > uses cases, since such use cases can already be supported using > OAuth 2.0. > > Denis > >> ᐧ >> >> 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-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 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 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 >> >>> 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) >>> >>> o may want access to resources at a Resource Server >>> o may be interacting with a User and want identity >>> claims about the User >>> o requests the Grant Service to grant resource access >>> and identity claims >>> * >>> >>> *Grant Server* (GS) >>> >>> o accepts Grant requests from the GC for resource >>> access and identity claims >>> o negotiates the interaction mode with the GC if >>> interaction is required with the User >>> o acquires authorization from the User before granting >>> identity claims to the GC >>> o acquires authorization from the RO before granting >>> resource access to the GC >>> o grants resource access and identity claims to the GC >>> * >>> >>> *Resource Server* (RS) >>> >>> o has resources that the GC may want to access >>> o expresses what the GC must obtain from the GS for >>> access through documentation or an API. This is not >>> in scope for this document >>> o verifies the GS granted access to the GC, when the >>> GS makes resource access requests >>> >>> *Humans* >>> >>> * >>> >>> *User* >>> >>> o the person interacting with the Grant Client. >>> o has delegated access to identity claims about >>> themselves to the Grant Server. >>> o may authenticate at the GS.. >>> * >>> >>> *Resource Owner* (RO) >>> >>> o the legal entity that owns resources at the Resource >>> Server (RS). >>> o has delegated resource access management to the GS. >>> o 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 >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------72A3B0F0E27804757EF7A67B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Dick,

      While I disagree with your interpretation of the charter -- I'll give you another example.

      One of my use cases is for the GC to retrieve Claims directly from the GS. There is no RS, so querying an RS first does not make sense.

      So, let us notice this disagreement.

      I was only discussing the very first exchange from the figure inserted in section 1.2. The use case you mention has nothing to do with section 1.2.
      Moreover, the example you mention is not described, nor illustrated by any figure in the draft.

      Nevertheless, the use case you mention is straightforward.  A User should be able to query at any time both the attributes and the capabilities,
      if any, that are registered by the AS. We should define a protocol for this retrieval.

      BTW, the sentence you are using includes the word "Claims" which is currently left undefined, since Section 5 from [OIDC] does not provide
      any formal definition for it.

      Denis

      On Tue, Aug 18, 2020 at 12:46 PM Denis <denis.ietf@free.fr> wrote:
      Hi Dick,
      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.

       I don't believe so.  The charter states: "It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect ..."

      The charter also states: "This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions
      not necessarily compatible with OAuth 2.0".

      We are not necessarily going to support all the current OAuth 2.0 uses cases, since such use cases can already be supported using OAuth 2.0.

      Denis

      ᐧ

      On Tue, Aug 18, 2020 at 10:29 AM Denis <denis.ietf@free.fr> 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"

      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 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

      Hello

      I just pushed an updated version of XAuth:


      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


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


      --------------72A3B0F0E27804757EF7A67B-- From nobody Wed Aug 19 01:50:13 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 4C1D33A1452 for ; Wed, 19 Aug 2020 01:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=udelt-no.20150623.gappssmtp.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 YzNi4_5PIaa6 for ; Wed, 19 Aug 2020 01:50:09 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0: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 C1A9E3A1451 for ; Wed, 19 Aug 2020 01:50:09 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id v21so18449591otj.9 for ; Wed, 19 Aug 2020 01:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JDUZUsXi89lTNS2RduEqaHmT7Xb1UrvJBBkWNk1VDW4=; b=yMIKHm7oaGfJH8QIjHZQW8UC5eJBdHCoYWpunFpJ3KUtX66FsDB97TtlfkBTFmtlOp /JJ0YG1krB8V9zsT5GFT3upLDMYBsRgR676Xao7xlMlSPDTpWggftV40amxePaRbbmWd h1fFGSGpmzl8c0zuMJNLe7XMaTZgYUqTZKhtsI+HyBeJBI/tcTlTIcBxCfcuVXpA/EWo RryABFHDRcQI7hlfl7+b6P+IlGxwmDZpDr3IybKID6OZ0nk3UURuwUc2OYKD6goRVBbc EYQ1ZdokQvbP/zcLdxd200CzGMFpZusAgkF/1aK7RH6YRGlFTHC2uPq9gMVLYPH3spFq U3FA== 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=JDUZUsXi89lTNS2RduEqaHmT7Xb1UrvJBBkWNk1VDW4=; b=MI/CT6yhUgXT5deSlHT2N4ercP3Wn9ohC2JkSTFMK5Maas2HtPzhSq4i+aqJUD+boU ExxRUpCi+B16JryuD7s0ACePTUDzskEkBJj25wM64dLaF+edt3jPxmntfuAS1WBvuKQW gqbpMMB10t+G0oXc5SYen0aXAqYoAaWh7iBI6j1YnEYF8LP5jR66K3DaNQd8jVy3ZNNR QtNKq6NdHaE1diqTJQ6BqjEaUoAVnSjmgjdWcS5UDu2JiwxuNr5IfOK+E36VD35QmeIQ MlmaV2uAUvxtFVV+g3Wf+l1wWs8udLk1+0V8nIjuyrGiL63G6UoFW3MQBse5w+2V+EKD lkNw== X-Gm-Message-State: AOAM530W+ouM11NAS+W9TJCZgr+KqT1zLnPGk1a69VwEgCjde4BggspP MLzzUGy4v8U5kyJLtwZ8GFJXYBrjHQNEc2vqI+/rHQ== X-Google-Smtp-Source: ABdhPJzGMpajA7Uf9N7W+uD1Y3x5O8JjSa9hR1kgFsjYFVCkzbzw1I7Jv9pRTzRkwFIW5sDYrDyR9tU9z+JNACt+HD8= X-Received: by 2002:a9d:38f:: with SMTP id f15mr18344475otf.74.1597827008436; Wed, 19 Aug 2020 01:50:08 -0700 (PDT) MIME-Version: 1.0 References: <018901d6719f$22593a20$670bae60$@prodigy.net> <9db6ee29-9e43-5893-6779-e5f863418890@free.fr> <015801d67245$933b3850$b9b1a8f0$@prodigy.net> <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> <01fd01d67585$fca832f0$f5f898d0$@prodigy.net> <0c2e0e75-808c-2859-3bad-e1b5cadda9ee@free.fr> In-Reply-To: <0c2e0e75-808c-2859-3bad-e1b5cadda9ee@free.fr> From: Steinar Noem Date: Wed, 19 Aug 2020 10:49:56 +0200 Message-ID: To: Denis Cc: nadalin@prodigy.net, txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000040366e05ad371729" Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Wed, 19 Aug 2020 08:50:12 -0000 --00000000000040366e05ad371729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I personally like FIDO2 a lot, and think that it would serve well as an example of how to solve authentication. But I also think that it is just one of many examples of how authentication can be handled, and that it should not be presented as a "preferred" solution or any other form of tight coupling between FIDO and GNAP. There are well founded reasons for choosing other mechanisms (e.g. national eIDs etc). -S ons. 19. aug. 2020 kl. 10:39 skrev Denis : > Hi Tony, > > Functionally, private keys are stored and used by the authenticator. For > capacity limitations, they can be stored elsewhere if both correctly > integrity and confidentiality protected. > That additional storage is an extension of the limited storage of the > authenticator. > > I was attempting to promote the use of FIDO within this WG. Are you > against or in favour of such a possibility ? > > Denis > > U2F is not CTAP2 or FIDO2, U2F device usually do not store the > cryptographic material on the device as the device has limited capabiliti= es > > > > *From:* Denis > *Sent:* Tuesday, August 18, 2020 9:37 AM > *To:* nadalin@prodigy.net; txauth@ietf.org > *Subject:* Re: [GNAP] Support of FIDO > > > > Hi Tony, > > Not quite Dennis, the U2F device does not store the private key, it only > creates the private key. > > Please read the Client to Authenticator Protocol (CTAP) specification fro= m > the FIDO Alliance: > > > https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authe= nticator-protocol-v2.0-ps-20190130.pdf > > Extract: > > (...) the ASPSP (Account Servicing Payment Service Providers) server > sends a challenge message to the authenticator > which is then cryptographically signed by a *private key stored in the > authenticator.* > > Denis > > > > *From:* TXAuth *On > Behalf Of *Denis > *Sent:* Friday, August 14, 2020 3:04 AM > *To:* nadalin@prodigy.net; txauth@ietf.org > *Subject:* Re: [GNAP] Support of FIDO > > > > Hi Tony, > > Dennis, not all the way correct > > 1. It is also possible to get rid of IDs and passwords using FIDO. > FIDO discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS > > Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D PII= , there can be > all sorts of information passed in ClientData field of the FIDO response, > not desirable but perfectly OK > > 1. None of these two semantics fit with the FIDO use case where the > subject value is scoped to be locally unique in the context of one RS. > Hence, the linkage of users between two RSs (or between one RS and any > other server) becomes impossible > > There is nothing that prohibits the RS from sharing registration > information between RS > > I am speaking of FIDO U2F where there are two main phases: registration > and authentication. > > The U2F device gives the public key and a Key Handle to the origin online > service or website during the user registration step. > Later, when the user performs an authentication, the origin online servic= e > or website sends the Key Handle back to the U2F device > via the browser. The U2F device uses the Key Handle to identify the user'= s > private key, and creates a signature which is sent back > to the origin to verify the presence of the U2F device. Thus, the Key > Handle is simply an identifier of a particular key on the U2F device. > > There is no other registration information needed. Sharing such an > information between RSs does not allow to link user accounts. > > Denis > > > > *From:* TXAuth *On > Behalf Of *Denis > *Sent:* Thursday, August 13, 2020 10:31 AM > *To:* txauth@ietf.org > *Subject:* [GNAP] Support of FIDO > > > > This topic has already been tackled on the list, but I open a new thread > for it. > > In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since > the solution in OAuth 2.0 was to use access tokens, > there have been used everywhere, even when they were not strictly needed. > > > > It is also possible to get rid of IDs and passwords using FIDO. FIDO > discloses no private information at all about the user > and no trust relationships need to be defined since there is no AS. > > > > FIDO should be one allowed possibility for the user authentication. In th= e > case of FIDO, the user is authenticated under a pseudonym > specific to the RS. It may observed that there is no equivalent in OAuth > because of the two different semantics of the subject claim. > > > > RFC 7519 states: > > The "sub" (subject) claim identifies the principal that is the subject of > the JWT. The claims in a JWT are normally statements about the subject. > The subject value MUST either be scoped to be locally unique in the > context of the issuer or be globally unique. > > In one case, it is possible to link the subject claim of two users betwee= n > two RSs (i.e. using a locally unique identifier in the context of the > issuer) > while in the other case (i.e. using a globally unique identifier) it is > possible, in addition, to link the subject claim between one RS and any > other server > (i.e. not supporting OAuth) that is using the same globally unique > identifier. > > > > None of these two semantics fit with the FIDO use case where the subject > value is scoped to be locally unique in the context of one RS. > > Hence, the linkage of users between two RSs (or between one RS and any > other server) becomes impossible. > > > > There are cases where a user would like to enjoy the unlinkeability > properties of FIDO which cannot be met using the claims currently defined > in OAuth. > > > > Denis > > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --00000000000040366e05ad371729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      I personally like FIDO2 a lot, and think that it would ser= ve well as an example of how to solve authentication.=C2=A0
      But I also = think that it is just one of many examples of how authentication can be han= dled, and that it should not be presented as a "preferred" soluti= on or any other form of tight=C2=A0coupling between FIDO and GNAP.=C2=A0There are well founded reasons for choosing other mechanisms (e.g. nation= al eIDs etc).

      -S

      ons. 19. aug. 2020 k= l. 10:39 skrev Denis <denis.ietf@f= ree.fr>:
      =20 =20 =20
      Hi Tony,

      Functionally, private keys are stored and used by the authenticator. For capacity limitations, they can be stored elsewhere if both correctly integrity and confidentiality protected.
      That additional storage is an extension of the limited storage of the authenticator.

      I was attempting to promote the use of FIDO within this WG. Are you against or in favour of such a possibility ?

      Denis

      =20 =20 =20

      U2F is not CTAP2 or FIDO2, U2F device usually do not store the cryptographic material on the device as the device has limited capabilities

      =C2=A0

      From: Denis <d= enis.ietf@free.fr>
      Sent: Tuesday, August 18, 2020 9:37 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO

      =C2=A0

      Hi Tony,

      Not quite Dennis, the U2F device does not store the private key, it only creates the private key.<= /p>

      Please read the Client to Authenticator Protocol (CTAP) specification from the FIDO Alliance:

      https://fidoall= iance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol= -v2.0-ps-20190130.pdf

      Extract:<= /u>

      =C2=A0(...) the ASPSP=C2=A0 (Account Servicing Payment Service Providers) server sends a challenge message to the authenticator
      which is then cryptographically signed by a private key stored in the authenticator.

      Denis=

      =C2=A0

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Friday, August 14, 2020 3:04 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of FIDO<= /p>

      =C2=A0

      Hi Tony,

      Dennis, not all the way correct

      1. It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
        and no trust relationships need to be defined since there is no AS

      Depends on if you only consider =E2=80=9Cprivate information=E2=80= =9D PII, there can be all sorts of information passed in ClientData field of the FIDO response, not desirable but perfectly OK

      1. None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.
        Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible

      There is nothing that prohibits the RS from sharing registration information between RS

      I am speaking of FIDO U2F where there are two main phases: registration and authentication.

      The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step.
      Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device
      via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back
      to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

      There is no other registration information needed. Sharing such an information between RSs does not allow to link user accounts.

      Denis=

      =C2=A0

      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Denis
      Sent: Thursday, August 13, 2020 10:31 AM
      To: txauth@ietf.org
      Subject: [GNAP] Support of FIDO

      =C2=A0

      This topic has already been tackled on the list, but I open a new thread for it.

      In OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since the solution in OAuth 2.0 was to use access tokens,
      there have been used everywhere, even when they were not strictly needed.



      It is also possible to get rid of IDs and passwords using FIDO. FIDO discloses no private information at all about the user
      and no trust relationships need to be defined since there is no AS.



      FIDO should be one allowed possibility for the user authentication. In the case of FIDO, the user is authenticated under a pseudonym
      specific to the RS. It may observed that there is no equivalent in OAuth because of the two different semantics of the subject claim.



      RFC 7519 states:

      The "sub" (subject) claim identifies the principa= l that is the subject of the JWT.=C2=A0 The claims in a JWT ar= e normally statements about the subject.=C2=A0
      The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

      In one case, it is possible to link the subject claim of two users between two RSs (i.e. using a locally unique identifier in the context of the issuer)
      while in the other case (i.e. using a=C2=A0globally uniqu= e identifier) it is possible, in addition, to link the subject claim between one RS and any other server
      (i.e. not supporting OAuth) that is using the same globally unique identifier.



      None of these two semantics fit with the FIDO use case where the subject value is scoped to be locally unique in the context of one RS.

      Hence, the linkage of users between two RSs (or between one RS and any other server) becomes impossible.



      There are cases where a user would like to enjoy the unlinkeability properties of FIDO which cannot be met using the claims currently defined in OAuth.



      Denis

      =C2=A0

      =C2=A0


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


      --
      Vennlig hilsen=

      Steinar Noem
      Partner Udelt AS
      Systemutvikler<= /div>
      =C2=A0
      |=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
      --00000000000040366e05ad371729-- From nobody Wed Aug 19 03:31:28 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 D8A113A120E for ; Wed, 19 Aug 2020 03:31:25 -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 0ugyzZxg2VV6 for ; Wed, 19 Aug 2020 03:31:23 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 D840D3A1751 for ; Wed, 19 Aug 2020 03:31:22 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id g19so24173854ioh.8 for ; Wed, 19 Aug 2020 03:31:22 -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=v7aHHa4zC/6TQl+/qhpGkC+L6aE4aeAEqHZeTz1Hkio=; b=taZmmO+r54aRmu/aY4w/xMRoo/Oe2j37f+TlRJWsO0EYHzd6FkLB4JK39ODf1GXXlf xS+FBEkhrBESyIDJNnpo6oWB1SPMxYRfcZWGC6TCovZ5udBtkDDy8BvghfBk9SP3cuIE I1UJR2MzNQ2TVdF4IjwFLDEWElbtnNB8zDXc5jAsYhikDQFe/u2K03q3X+1l6hG8a+Pj i0kYiqbmbxdIKfBidrIJaix4PS+5IPbyOEL4uNF1CknNazFRXg5GUuwnh1ZUDWRIxDYe 4DzGVI7O/xIDcsHGxxTictSMoiu0oit4dyP6xtEK/stxgDKckPOLf7K42FnUWKZDdq/n jyvA== 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=v7aHHa4zC/6TQl+/qhpGkC+L6aE4aeAEqHZeTz1Hkio=; b=ZxiBIaO6yvvbk0d87wxXCeeriA1/WXjoV4A44QPxJairL47z3dviHwvLa5eyeLjv7E iEnvMlyS7Sao+XEHazUUL/exBCdchN+BOO4Uo+pl6kKViZarm0eqUZIlpVYxUC54Ox39 BsmXQYsrYSwfGYnUTgdnluV7tNrSvQxPG7unGRJOQndUzwtd1TrSeKP7z43mxRFyupfH DtwVCTUjGaQzaHUDEzOjWbqSG63xNwAvcGbzlPns1fgBi+AGnNa7w02G83rtYPjxMGCK mHUsKITsW5PDsSqWehpnRWYM1/2mjtcGaR78eh4ChxtDpHZ7a3jaYoPNm7znnifzYuF3 sHpA== X-Gm-Message-State: AOAM5321JapxJih8a4O4YBYiXr65QPPlS7vbk5uUXKVL0E9kNsNGpzY3 HkedGCWTm/ySrtoa5WWe7P3Zo17qkxNq4FPK56Q= X-Google-Smtp-Source: ABdhPJyr0v/+35fsLQwijSxW0e76YdI/5mMBY2/KcNu6eprZpaPQ7rfXEcq8DVu1kADyazOtLZ8zWmynv0TBP4iY/So= X-Received: by 2002:a6b:e70d:: with SMTP id b13mr19904894ioh.141.1597833080461; Wed, 19 Aug 2020 03:31:20 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> In-Reply-To: From: Fabien Imbault Date: Wed, 19 Aug 2020 12:31:08 +0200 Message-ID: To: Dick Hardt Cc: Francis Pouatcha , Denis , "txauth@ietf.org" , Justin Richer Content-Type: multipart/alternative; boundary="0000000000002bdf5105ad388102" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 19 Aug 2020 10:31:26 -0000 --0000000000002bdf5105ad388102 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just wondering if that might be a way to compose the generic transaction/continuation pattern (XYZ style, layer 1) from a lower-level GS-API (layer 0). Fabien On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt wrote: > Hi Francis > > I have come to a similar conclusion. I'll be posting my thoughts in a > concrete proposal and am keen to hear how it fits into how your mental > model. > > /Dick > =E1=90=A7 > > On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha 40adorsys.de@dmarc.ietf.org> wrote: > >> Lots of mails, so I will summarize my opinion in this single mail: >> >> We are dealing with different levels of abstraction here, this is why we >> are always falling back to wording battles. >> >> oAuth2/OIDC vs. GNAP >> AS vs. GS/DS/IS >> Entity vs. Roles >> User (human) vs. Requestor >> Client vs (Orchestrator/Requesting Party/Negotiator...) >> front-channel & back-channel >> >> To direct the discussion, we have to agree on the level of abstraction a= t >> which we want a certain discussion to take place. >> >> Abstraction Level-0: GNAP >> >> Level-0 deals with roles (participants) and messages (request/responses)= . >> Level-0 does not consider entities (users) or the nature of any other >> participants, neither Level-0 deals with the way a message is transporte= d >> (synchronous/asynchronous) or the type of interaction used to materializ= e >> the message (front-channel, back-channel). The purpose of this abstracti= on >> layer is to provide a common understanding of the core elements of the >> protocol. >> >> Level-0 can still provide some basic definition of messages including >> information schema as long as we are not limiting the protocol with >> constraints from lower layers. >> >> Level-0 is ideal to address some fundamental privacy and confidentiality >> matters that will be materialized in lower layers. >> >> Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC] >> Instantiation of Level-0 for a constrained application space. This is wh= y >> we will meet the world Client, User, RO, AS, .... here roles defined in >> Level-0 will be mapped to entities, interaction will be used to material= ize >> messages defined in Level-0. >> The protocol mapping at this layer also takes into consideration that >> some of those participants are human or only pieces of software, running= on >> the user device or on a server with consequences on the protocol design. >> >> Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / .... >> >> In Summary: >> Level-0: Roles, Messages >> Level-1: Entities, Interactions >> ... >> >> And if it happens we want to define GNAP at Level-1 (instead of 0), let >> declare it as such and limit the application space before we proceed wit= h >> further discussions. >> >> Best regards. >> /Francis >> >> >> >> >> On Thu, Aug 13, 2020 at 1:30 PM Denis wrote: >> >>> Justin, >>> >>> Your response does not address my point. I am talking of two different >>> channels with the RS, i.e. not with the AS. >>> >>> Denis >>> >>> Denis, I want to focus on one point here: >>> >>> In OAuth 2.0, the user consent is performed by the AS using an authoriz= e >>> endpoint where the user consent is solicited and captured. >>> >>> Since a user, with no prior experience, shall first connect to a RS to >>> perform an operation, the user consent shall be performed by the RS, >>> instead of the AS. This means that we should define a "consent" >>> endpoint at the RS. >>> >>> >>> One of my goals with XYZ=E2=80=99s design was to be able to separate th= e >>> interaction with the user from the web-based flows for the delegation >>> protocol, and that aspect is enshrined in the GNAP charter as well. >>> >>> It points to the reality that there are two different aspects of the >>> traditional AS that we might need to talk about separately now. One dea= ls >>> with delegation, issuing tokens, returning data directly to the client = (not >>> through a separate API, since that=E2=80=99s the RS), and other back-ch= annel stuff. >>> The other aspect deals with interacting with the user and/or resource >>> owner. >>> >>> We already saw bits of this in OAuth 2: the AS is defined by the pair o= f >>> the token endpoint and authorization endpoint, each filling the respect= ive >>> roles above. What if we formally separate these? Strawman names: >>> >>> Delegation Server (DS) - handles the back-channel stuff >>> >>> Interaction Server (IS) - handles the front-channel stuff >>> >>> >>> =E2=80=94 Justin >>> >>> >>> -- >>> 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/ >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000002bdf5105ad388102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Just wondering if that might be a way to compose the gener= ic transaction/continuation pattern (XYZ style, layer 1) from a lower-level= GS-API (layer 0).
      Fabien

      On Thu, Aug 13, 2020 at 9:28 PM Dick Har= dt <dick.hardt@gmail.com>= wrote:
      Hi Francis

      I have=C2=A0come to a similar conclu= sion. I'll be posting my thoughts in a concrete proposal and am keen to= hear how it fits into how your mental model.

      /Dic= k
      =E1=90=A7

      On Thu, Aug 13, 2020 at 12:00 P= M Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
      Lots of mail= s, so I will summarize=C2=A0my opinion in this single mail:

      <= div>We are dealing with different levels of abstraction here, this is why w= e are always=C2=A0falling back to wording battles.

      o= Auth2/OIDC vs. GNAP
      AS vs. GS/DS/IS
      Entity vs. = Roles
      User (human) vs. Requestor
      Client vs (Orchestrato= r/Requesting Party/Negotiator...)
      front-channel & back-channe= l

      To direct the discussion, we have to = agree on the level of abstraction at which we want a certain discussion to = take place.

      Abstraction Level-0: GNAP
      Level-0 deals with roles (participants) and messages (request/= responses). Level-0 does not consider entities (users) or the nature of any= other participants,=C2=A0neither Level-0 deals with the way a message is t= ransported (synchronous/asynchronous) or the type of interaction used to ma= terialize the message (front-channel, back-channel). The purpose of this ab= straction layer is to provide a common understanding of the core elements o= f the protocol.=C2=A0

      Level-0 can still provide so= me basic definition of messages including information schema as long as we = are not limiting the protocol with constraints from lower layers.

      Level-0 is ideal to address some fundamental privacy and co= nfidentiality matters that will be materialized in lower layers.
      =
      Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC]
      = Instantiation of Level-0 for a constrained application space. This is why w= e will meet the world Client, User, RO, AS, .... here roles defined in Leve= l-0 will be mapped to entities, interaction will be used to materialize mes= sages defined in Level-0.=C2=A0
      The protocol mapping at this laye= r also takes into consideration that some of those participants are human o= r only pieces of software, running on the user device or on a server with c= onsequences on the protocol design.

      Abstraction Le= vel-2: Trust Frameworks like IAM / PSD2,FAPI / ....

      In Summary:
      Level-0: Roles, Messages
      Level-1: Entitie= s, Interactions
      ...

      And if it happens we= want to define GNAP at Level-1 (instead of 0), let declare it as such and = limit the application space before we proceed with further discussions.

      Best regards.
      /Francis

      =



      On Thu, Aug 13, 2020 at 1:30 PM Denis &= lt;denis.ietf@free.= fr> wrote:
      =20 =20 =20
      =C2=A0Justin,

      Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

      Denis

      =20 Denis, I want to focus on one point here:

      In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

      Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
      instead of the AS. = This means that we should define a "consent" end= point at the RS.

      One of my goals with XYZ=E2=80=99s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

      It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that=E2=80=99s the RS), and other back-channel stuff. = The other aspect deals with interacting with the user and/or resource owner.=C2=A0

      We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

      Delegation Server (DS) - handles the back-channel stuff

      Interaction Server (IS) - handles the front-channel stuff


      =C2=A0=E2=80=94 Justin


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


      --
      Francis Pouatcha
      Co-Founder and Technical Lead=
      adorsys GmbH & Co. KG
      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --0000000000002bdf5105ad388102-- From nobody Wed Aug 19 08:09:31 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 D984B3A0826 for ; Wed, 19 Aug 2020 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 MBXd78T6AJ2d for ; Wed, 19 Aug 2020 08:09:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E613A0821 for ; Wed, 19 Aug 2020 08:09:27 -0700 (PDT) Received: from [192.168.1.11] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07JF9J6v028366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Aug 2020 11:09:20 -0400 From: Justin Richer Message-Id: <01AD8BB1-F40D-497B-948D-4C08A5155CCA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B46DE26-7D7D-4AC0-A6F4-18D6D98300A4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 19 Aug 2020 11:09:19 -0400 In-Reply-To: Cc: Dick Hardt , Francis Pouatcha , Denis , "txauth@ietf.org" To: Fabien Imbault References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 19 Aug 2020 15:09:30 -0000 --Apple-Mail=_1B46DE26-7D7D-4AC0-A6F4-18D6D98300A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In my perspective, the focus should be on defining the protocol: what = you=E2=80=99d call the transaction pattern. We can potentially use a API = language to describe how an entity can perform a role within that = protocol, but ultimately we should be defining the protocol. =E2=80=94 Justin > On Aug 19, 2020, at 6:31 AM, Fabien Imbault = wrote: >=20 > Just wondering if that might be a way to compose the generic = transaction/continuation pattern (XYZ style, layer 1) from a lower-level = GS-API (layer 0). > Fabien >=20 > On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt > wrote: > Hi Francis >=20 > I have come to a similar conclusion. I'll be posting my thoughts in a = concrete proposal and am keen to hear how it fits into how your mental = model. >=20 > /Dick > =E1=90=A7 >=20 > On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha = > = wrote: > Lots of mails, so I will summarize my opinion in this single mail: >=20 > We are dealing with different levels of abstraction here, this is why = we are always falling back to wording battles. >=20 > oAuth2/OIDC vs. GNAP > AS vs. GS/DS/IS > Entity vs. Roles > User (human) vs. Requestor > Client vs (Orchestrator/Requesting Party/Negotiator...) > front-channel & back-channel >=20 > To direct the discussion, we have to agree on the level of abstraction = at which we want a certain discussion to take place. >=20 > Abstraction Level-0: GNAP >=20 > Level-0 deals with roles (participants) and messages = (request/responses). Level-0 does not consider entities (users) or the = nature of any other participants, neither Level-0 deals with the way a = message is transported (synchronous/asynchronous) or the type of = interaction used to materialize the message (front-channel, = back-channel). The purpose of this abstraction layer is to provide a = common understanding of the core elements of the protocol.=20 >=20 > Level-0 can still provide some basic definition of messages including = information schema as long as we are not limiting the protocol with = constraints from lower layers. >=20 > Level-0 is ideal to address some fundamental privacy and = confidentiality matters that will be materialized in lower layers. >=20 > Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC] > Instantiation of Level-0 for a constrained application space. This is = why we will meet the world Client, User, RO, AS, .... here roles defined = in Level-0 will be mapped to entities, interaction will be used to = materialize messages defined in Level-0.=20 > The protocol mapping at this layer also takes into consideration that = some of those participants are human or only pieces of software, running = on the user device or on a server with consequences on the protocol = design. >=20 > Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / .... >=20 > In Summary: > Level-0: Roles, Messages > Level-1: Entities, Interactions > ... >=20 > And if it happens we want to define GNAP at Level-1 (instead of 0), = let declare it as such and limit the application space before we proceed = with further discussions. >=20 > Best regards. > /Francis >=20 >=20 >=20 >=20 > On Thu, Aug 13, 2020 at 1:30 PM Denis > wrote: > Justin, >=20 > Your response does not address my point. I am talking of two different = channels with the RS, i.e. not with the AS. >=20 > Denis >=20 >> Denis, I want to focus on one point here: >>=20 >>> In OAuth 2.0, the user consent is performed by the AS using an = authorize endpoint where the user consent is solicited and captured. >>>=20 >>> Since a user, with no prior experience, shall first connect to a RS = to perform an operation, the user consent shall be performed by the RS,=20= >>> instead of the AS. This means that we should define a "consent" = endpoint at the RS. >>=20 >> One of my goals with XYZ=E2=80=99s design was to be able to separate = the interaction with the user from the web-based flows for the = delegation protocol, and that aspect is enshrined in the GNAP charter as = well. >>=20 >> It points to the reality that there are two different aspects of the = traditional AS that we might need to talk about separately now. One = deals with delegation, issuing tokens, returning data directly to the = client (not through a separate API, since that=E2=80=99s the RS), and = other back-channel stuff. The other aspect deals with interacting with = the user and/or resource owner.=20 >>=20 >> We already saw bits of this in OAuth 2: the AS is defined by the pair = of the token endpoint and authorization endpoint, each filling the = respective roles above. What if we formally separate these? Strawman = names: >>=20 >> Delegation Server (DS) - handles the back-channel stuff >>=20 >> Interaction Server (IS) - handles the front-channel stuff >>=20 >>=20 >> =E2=80=94 Justin >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/ = --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_1B46DE26-7D7D-4AC0-A6F4-18D6D98300A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = my perspective, the focus should be on defining the protocol: what = you=E2=80=99d call the transaction pattern. We can potentially use a API = language to describe how an entity can perform a role within that = protocol, but ultimately we should be defining the protocol.

       =E2=80=94 = Justin

      On Aug 19, 2020, at 6:31 AM, Fabien Imbault = <fabien.imbault@gmail.com> wrote:

      Just wondering if that might be a = way to compose the generic transaction/continuation pattern (XYZ style, = layer 1) from a lower-level GS-API (layer 0).
      Fabien

      On Thu, Aug = 13, 2020 at 9:28 PM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi = Francis

      I = have come to a similar conclusion. I'll be posting my thoughts in a = concrete proposal and am keen to hear how it fits into how your mental = model.

      /Dick
      3D""=E1=90=A7

      On Thu, Aug = 13, 2020 at 12:00 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
      Lots of = mails, so I will summarize my opinion in this single mail:

      We are dealing with = different levels of abstraction here, this is why we are = always falling back to wording battles.

      oAuth2/OIDC vs. GNAP
      AS vs. GS/DS/IS
      Entity vs. Roles
      User (human) vs. = Requestor
      Client vs (Orchestrator/Requesting = Party/Negotiator...)
      front-channel & = back-channel

      To direct the discussion, we have to = agree on the level of abstraction at which we want a certain discussion = to take place.

      Abstraction Level-0: GNAP

      Level-0 deals with roles (participants) = and messages (request/responses). Level-0 does not consider entities = (users) or the nature of any other participants, neither Level-0 = deals with the way a message is transported (synchronous/asynchronous) = or the type of interaction used to materialize the message = (front-channel, back-channel). The purpose of this abstraction layer is = to provide a common understanding of the core elements of the = protocol. 

      Level-0 can still provide some basic definition of messages = including information schema as long as we are not limiting the protocol = with constraints from lower layers.

      Level-0 is ideal to address some = fundamental privacy and confidentiality matters that will be = materialized in lower layers.

      Abstraction Level-1: OAuth2 / OIDC / = [SSI/DiD/VC]
      Instantiation of Level-0 for a = constrained application space. This is why we will meet the world = Client, User, RO, AS, .... here roles defined in Level-0 will be mapped = to entities, interaction will be used to materialize messages defined in = Level-0. 
      The protocol mapping at this layer = also takes into consideration that some of those participants are human = or only pieces of software, running on the user device or on a server = with consequences on the protocol design.

      Abstraction Level-2: Trust Frameworks = like IAM / PSD2,FAPI / ....

      In Summary:
      Level-0: Roles, = Messages
      Level-1: Entities, Interactions
      ...

      And if it happens we want to define GNAP at Level-1 (instead = of 0), let declare it as such and limit the application space before we = proceed with further discussions.

      Best regards.
      /Francis




      On Thu, Aug = 13, 2020 at 1:30 PM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20
       Justin,

      Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

      Denis

      =20 Denis, I want to focus on one point here:

      In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

      Since a user, with no prior experience, shall first connect to a RS to perform an operation, = the user consent shall be performed by the RS,
      instead of the AS. = This means that we should define a "consent" endpoint at the RS.

      One of my goals with XYZ=E2=80=99s design was to = be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

      It points to the reality that there are two = different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that=E2=80=99s the RS), and other back-channel = stuff. The other aspect deals with interacting with the user and/or resource owner. 

      We already saw bits of this in OAuth 2: the AS = is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

      Delegation Server (DS) - handles the = back-channel stuff

      Interaction Server (IS) - handles the = front-channel stuff


       =E2=80=94 Justin


      --
      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/
      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/mailman/listinfo/txauth
      =
      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/mailman/listinfo/txauth
      =

      = --Apple-Mail=_1B46DE26-7D7D-4AC0-A6F4-18D6D98300A4-- From nobody Wed Aug 19 08:10:44 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 52A883A0826 for ; Wed, 19 Aug 2020 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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=alkaline-solutions.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 mHojOMlnSD99 for ; Wed, 19 Aug 2020 08:10:40 -0700 (PDT) Received: from mail.alkaline-solutions.com (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCF43A0821 for ; Wed, 19 Aug 2020 08:10:39 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id E607A385FBB; Wed, 19 Aug 2020 15:10:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1597849835; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eR4mtQIx8YV8mN4+FQlN8BAErOgE2qPsP3qHrW0/HhU=; b=DtwbuWy73wIKbu54Ew7UhTWu/Axm93F9kyP6KkNE9dmHoRaS6WUFn5PnoLbU7Ihe/2J+Am abo0N9nu+HkFbf7SmmyJuekjtsl807vOcX1v5XrXfBWANvL4uVQdvtZ39sRXGknkKOybxq jzRz6jn7cxnP9As35B/UeQkTqni6jI4= From: David Waite Message-Id: <0B840714-47B6-44B1-BF21-98D6C032F9DA@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F9A8470-422B-4FA1-8AB8-CC69BC2AD7B3" Mime-Version: 1.0 Date: Wed, 19 Aug 2020 09:10:32 -0600 In-Reply-To: <9b1b3fa0-9b91-7bb0-2418-2c96518044a8@free.fr> Cc: txauth@ietf.org, nadalin@prodigy.net To: Denis References: <96aaaff7-5f11-4c7b-bc93-d4d355284018@free.fr> <0E8FCF98-F5E7-4C1D-8491-96CFEF7AA3C4@alkaline-solutions.com> <9b1b3fa0-9b91-7bb0-2418-2c96518044a8@free.fr> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1597849836; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eR4mtQIx8YV8mN4+FQlN8BAErOgE2qPsP3qHrW0/HhU=; b=YIz1p2Dpkgq9jKAuvltDLO7+2BRgQsyZkAwLuSgyvG72xe3vog7tFxYws+HyxafNjEgHs3 SAAeOU4dpox7Eql1Us1Allp8jJuhvkuRhzkN9+S4fRj72+z7w6HHnynbMavfYzIYiz1CMD C5S2QgOCzGX3cK2ft3LObgvQE8g+orw= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1597849836; a=rsa-sha256; cv=none; b=MDsYU89r7nBRi4MN2sAE30A1yxiuWRYBk+xLZnzgs1Bg6yawwwgBPog4e9NvfKGGtb4xeN kMziHGVH9AH2pMoi4i3BsnydLJTtOKx9GVFHg+M8qDT5X+vPAWmcQvR8/ftDVMN6hx5MhX 8O0dv4ftygtoScYW2HfPjd8foqD0xjw= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: + Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Archived-At: Subject: Re: [GNAP] Support of FIDO 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: Wed, 19 Aug 2020 15:10:42 -0000 --Apple-Mail=_6F9A8470-422B-4FA1-8AB8-CC69BC2AD7B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 19, 2020, at 02:37, Denis wrote: >> U2F devices do not typically store private keys per site, but instead = rely on a =E2=80=9Ccredential handle=E2=80=9D presented by the RP which = contains an encrypted form of the key or keying material used to reserve = the key. Some CTAP2 implementations do store private keys even in U2F = compatibility mode, but these still require presentation of a credential = handle.=20 >>=20 >> So authentication either can use a CTAP2 authentication with a = previously created credential that is resident/discoverable, or you = perform some initial user authentication to determine which credential = handles are appropriate to challenge a U2F authenticator with > Such implementations details are not important for the present = discussion. The key question is whether FIDO authentication would be one = authentication possibility=20 > advertised by the RS and, if so, how the client should be informed of = it by the RS. >=20 Use cases and feasibility are complicated. Here are the use cases as I = understand them: 1. AS integration for user authentication: Short term, it is far easier to just have the browser do Web = Authentication of the user at the AS. Medium-term, user authentication to the AS is feasible for first-party = clients to the AS. Platforms have and are expected to continue locking = down access to CTAP2 over standardized transports and providing = Webauthn-like API access to those as well as to any integrated platform = authentication capabilities - and use entitlements and web-domain-based = discovery to determine which applications have access. These = applications are trusted not to use the credentials elsewhere, so for = example a browser needs special entitlements to be able to do WebAuthn = across all domains. I would expect this to be an interaction mode - with = challenge message and response very similar to the WebAuthn API = GetAssertion call, perhaps with Base64-encoded strings substituted for = ArrayBuffers. 2. AS integration for client authentication: It might make sense to create credentials for use to verify an authentic = client. This would be similar to a software statement when doing OAuth = DCR. DCAppAttestService is a feature coming in iOS 14 which will create an = attestation that the application instance is legitimate. The interface = for using these attestations is based heavily on Web Authentication, = although the client information block is free-form. Since the = attestations (hopefully) are distinct from platform attestations for = browser-based web authentication, there should not be a platform = restriction on acquiring these. I wouldn=E2=80=99t expect this to be a feature in the core specification = unless other platforms followed suit however - Google for instance has = SafetyNet instead.=20 3. RS integration for client authentication and user authentication: I suspect this goes counter to GNAP just how it would go counter to = OAuth - both policy and complexity are usually centralized by the AS. Of = course, if an RS is also an AS for its own domain, it would have the use = cases above. -DW >=20 > Denis >=20 >>=20 >> Sent from my iPhone >>=20 >>> On Aug 18, 2020, at 10:38 AM, Denis = wrote: >>>=20 >>> =EF=BB=BF >>> Hi Tony, >>>> Not quite Dennis, the U2F device does not store the private key, it = only creates the private key. >>> Please read the Client to Authenticator Protocol (CTAP) = specification from the FIDO Alliance: >>>=20 >>> = https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authen= ticator-protocol-v2.0-ps-20190130.pdf = >>> Extract: >>>=20 >>> (...) the ASPSP (Account Servicing Payment Service Providers) = server sends a challenge message to the authenticator >>> which is then cryptographically signed by a private key stored in = the authenticator. >>>=20 >>> Denis >>>=20 >>>> =20 >>>> From: TXAuth = On Behalf Of Denis >>>> Sent: Friday, August 14, 2020 3:04 AM >>>> To: nadalin@prodigy.net ; = txauth@ietf.org >>>> Subject: Re: [GNAP] Support of FIDO >>>> =20 >>>> Hi Tony,=20 >>>> Dennis, not all the way correct=20 >>>> It is also possible to get rid of IDs and passwords using FIDO. = FIDO discloses no private information at all about the user=20 >>>> and no trust relationships need to be defined since there is no AS >>>> Depends on if you only consider =E2=80=9Cprivate information=E2=80=9D= PII, there can be all sorts of information passed in ClientData field = of the FIDO response, not desirable but perfectly OK=20 >>>> None of these two semantics fit with the FIDO use case where the = subject value is scoped to be locally unique in the context of one RS.=20= >>>> Hence, the linkage of users between two RSs (or between one RS and = any other server) becomes impossible >>>> There is nothing that prohibits the RS from sharing registration = information between RS=20 >>>> I am speaking of FIDO U2F where there are two main phases: = registration and authentication. >>>>=20 >>>> The U2F device gives the public key and a Key Handle to the origin = online service or website during the user registration step.=20 >>>> Later, when the user performs an authentication, the origin online = service or website sends the Key Handle back to the U2F device=20 >>>> via the browser. The U2F device uses the Key Handle to identify the = user's private key, and creates a signature which is sent back=20 >>>> to the origin to verify the presence of the U2F device. Thus, the = Key Handle is simply an identifier of a particular key on the U2F = device. >>>>=20 >>>> There is no other registration information needed. Sharing such an = information between RSs does not allow to link user accounts. >>>>=20 >>>> Denis >>>>=20 >>>> =20 >>>> From: TXAuth = On Behalf Of Denis >>>> Sent: Thursday, August 13, 2020 10:31 AM >>>> To: txauth@ietf.org >>>> Subject: [GNAP] Support of FIDO >>>> =20 >>>> This topic has already been tackled on the list, but I open a new = thread for it. >>>>=20 >>>> In OAuth 2.0, one of the goals was to get rid of IDs and passwords. = Since the solution in OAuth 2.0 was to use access tokens,=20 >>>> there have been used everywhere, even when they were not strictly = needed.=20 >>>>=20 >>>>=20 >>>> It is also possible to get rid of IDs and passwords using FIDO. = FIDO discloses no private information at all about the user=20 >>>> and no trust relationships need to be defined since there is no AS.=20= >>>>=20 >>>>=20 >>>> FIDO should be one allowed possibility for the user authentication. = In the case of FIDO, the user is authenticated under a pseudonym=20 >>>> specific to the RS. It may observed that there is no equivalent in = OAuth because of the two different semantics of the subject claim. >>>>=20 >>>>=20 >>>> RFC 7519 states: >>>> The "sub" (subject) claim identifies the principal that is the = subject of the JWT. The claims in a JWT are normally statements about = the subject. =20 >>>> The subject value MUST either be scoped to be locally unique in the = context of the issuer or be globally unique. >>>> In one case, it is possible to link the subject claim of two users = between two RSs (i.e. using a locally unique identifier in the context = of the issuer)=20 >>>> while in the other case (i.e. using a globally unique identifier) = it is possible, in addition, to link the subject claim between one RS = and any other server=20 >>>> (i.e. not supporting OAuth) that is using the same globally unique = identifier. >>>>=20 >>>>=20 >>>> None of these two semantics fit with the FIDO use case where the = subject value is scoped to be locally unique in the context of one RS.=20= >>>>=20 >>>> Hence, the linkage of users between two RSs (or between one RS and = any other server) becomes impossible.=20 >>>>=20 >>>>=20 >>>> There are cases where a user would like to enjoy the unlinkeability = properties of FIDO which cannot be met using the claims currently = defined in OAuth. >>>>=20 >>>>=20 >>>> Denis >>>> =20 >>>>=20 >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_6F9A8470-422B-4FA1-8AB8-CC69BC2AD7B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

      On Aug 19, 2020, at 02:37, Denis <denis.ietf@free.fr> = wrote:
      U2F devices do not = typically store private keys per site, but instead rely on a = =E2=80=9Ccredential handle=E2=80=9D presented by the RP which contains = an encrypted form of the key or keying material used to reserve the key. = Some CTAP2 implementations do store private keys even in U2F = compatibility mode, but these still require presentation of a credential = handle. 

      So= authentication either can use a CTAP2 authentication with a previously = created credential that is resident/discoverable, or you perform some = initial user authentication to determine which credential handles are = appropriate to challenge a U2F authenticator with

      Such = implementations details are not important for the present discussion. = The key question is whether FIDO authentication would be one = authentication possibility 
      advertised = by the RS and, if so, how the client should be informed of it by the = RS.

      Use cases and feasibility are = complicated. Here are the use cases as I understand them:

      1. AS integration for user = authentication:
      Short term, it is far easier to just have the = browser do Web Authentication of the user at the AS.

      Medium-term, user authentication to the AS is = feasible for first-party clients to the AS. Platforms have and are = expected to continue locking down access to CTAP2 over standardized = transports and providing Webauthn-like API access to those as well as to = any integrated platform authentication capabilities - and use = entitlements and web-domain-based discovery to determine which = applications have access. These applications are trusted not to use the = credentials elsewhere, so for example a browser needs special = entitlements to be able to do WebAuthn across all domains. I would = expect this to be an interaction mode - with challenge message and = response very similar to the WebAuthn API GetAssertion call, perhaps = with Base64-encoded strings substituted for ArrayBuffers.

      2. AS integration for client = authentication:
      It might make sense to create credentials for = use to verify an authentic client. This would be similar to a software = statement when doing OAuth DCR.

      DCAppAttestService is = a feature coming in iOS 14 which will create an attestation that the = application instance is legitimate. The interface for using these = attestations is based heavily on Web Authentication, although the client = information block is free-form. Since the attestations (hopefully) are = distinct from platform attestations for browser-based web = authentication, there should not be a platform restriction on acquiring = these.

      I wouldn=E2=80=99t expect = this to be a feature in the core specification unless other platforms = followed suit however - Google for instance has SafetyNet = instead. 

      3. RS integration for = client authentication and user authentication:
      I suspect this = goes counter to GNAP just how it would go counter to OAuth - both policy = and complexity are usually centralized by the AS. Of course, if an RS is = also an AS for its own domain, it would have the use cases = above.

      -DW


      Denis


      Sent from my iPhone

      On Aug 18, = 2020, at 10:38 AM, Denis <denis.ietf@free.fr> wrote:

      =EF=BB=BF
      Hi Tony,
      Not = quite Dennis, the U2F device does not store the private key, it only = creates the private key.

      Please read the Client to = Authenticator Protocol (CTAP) specification from the FIDO = Alliance:

      https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-clie= nt-to-authenticator-protocol-v2.0-ps-20190130.pdf

      Extract:

       (...) the = ASPSP  (Account Servicing Payment Service Providers) server sends a = challenge message to the authenticator
      which is then = cryptographically signed by a private key = stored in the authenticator.

      Denis

       
      From: TXAuth <txauth-bounces@ietf.org> On Behalf = Of Denis
      Sent: Friday, August 14, 2020 = 3:04 AM
      To: nadalin@prodigy.net; txauth@ietf.org
      Subject: Re: [GNAP] Support of = FIDO
       
      Hi = Tony, 
      Dennis, not all the = way correct 
      • It= is also possible to get rid of IDs and passwords using FIDO. FIDO = discloses no private information at all about the user 
        and no trust = relationships need to be defined since there is no AS
      Depends on if you only = consider =E2=80=9Cprivate information=E2=80=9D PII, there can be all = sorts of information passed in ClientData field of the FIDO response, = not desirable but perfectly OK 
      • None of these two semantics fit with the FIDO use case where = the subject value is scoped to be locally unique in the context of one = RS. 
        Hence, the linkage of users between two RSs (or between one = RS and any other server) becomes impossible
      There is nothing that = prohibits the RS from sharing registration information between RS 

      I am speaking of = FIDO U2F where there are two main phases: registration and = authentication.

      The = U2F device gives the public key and a Key Handle to the origin online = service or website during the user registration step. 
      Later, when = the user performs an authentication, the origin online service or = website sends the Key Handle back to the U2F device 
      via the = browser. The U2F device uses the Key Handle to identify the user's = private key, and creates a signature which is sent back 
      to the = origin to verify the presence of the U2F device. Thus, the Key Handle is = simply an identifier of a particular key on the U2F device.

      There is no other = registration information needed. Sharing such an information between RSs = does not allow to link user accounts.

      Denis

       
      From: TXAuth <txauth-bounces@ietf.org> On Behalf = Of Denis
      Sent: Thursday, August 13, 2020 = 10:31 AM
      To: txauth@ietf.org
      Subject: [GNAP] Support of FIDO
       
      This topic has already been tackled on = the list, but I open a new thread for it.

      In = OAuth 2.0, one of the goals was to get rid of IDs and passwords. Since = the solution in OAuth 2.0 was to use access tokens, 
      there have = been used everywhere, even when they were not strictly needed. 


      It is also possible to get rid of IDs and passwords using = FIDO. FIDO discloses no private information at all about the user 
      and no trust = relationships need to be defined since there is no AS. 


      FIDO should be one allowed possibility for the user = authentication. In the case of FIDO, the user is authenticated under a = pseudonym 
      specific to the RS. It may observed that there is no = equivalent in OAuth because of the two different semantics of the = subject claim.


      RFC 7519 states:
      The "sub" (subject) = claim identifies the principal that is the subject of the JWT.  The = claims in a JWT are normally statements about the subject.  
      The subject = value MUST either be scoped to be locally unique in the context of the = issuer or be globally unique.
      In one case, it is = possible to link the subject claim of two users between two RSs (i.e. = using a locally unique identifier in the context of the issuer) 
      while in the = other case (i.e. using a globally unique identifier) it is = possible, in addition, to link the subject claim between one RS and any = other server 
      (i.e. not supporting OAuth) that is using the same globally = unique identifier.


      None of these two semantics fit with the = FIDO use case where the subject value is scoped to be locally unique in = the context of one RS. 

      Hence, the linkage of users between two RSs (or between one = RS and any other server) becomes impossible. 


      There are cases where a user would like to enjoy the = unlinkeability properties of FIDO which cannot be met using the claims = currently defined in OAuth.


      Denis

       


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


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

      = --Apple-Mail=_6F9A8470-422B-4FA1-8AB8-CC69BC2AD7B3-- From nobody Wed Aug 19 10:16:05 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 134293A08D6 for ; Wed, 19 Aug 2020 10:16: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=unavailable 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 zT0qcj1BEaS6 for ; Wed, 19 Aug 2020 10:16:01 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 CD3A93A08DB for ; Wed, 19 Aug 2020 10:16:00 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id v6so25391569iow.11 for ; Wed, 19 Aug 2020 10:16:00 -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=Tm1Rrlzeiu2hYmomE6wgD9RmeVVX8cGTCCL6dvoZagg=; b=iKYr0kfNlf0Wqnhz4LhkzafRIKqh9J1/NZKff69/2JcPZgdaGsJXPdXrY9By4ktzNt zHQ0UPTbcfcmv1ljFP53MgnR6dfpEs0G2dpLTBj7Vw75sTg+DkKhE9cLbhknAqQe2gAq psNrXLzA5Gwdj8Jk8S8NFq5vYeBZGIw6xhQ+ger/xbr6Wb3FxlPIm/TMEFus6LU+gbjX 7z0s6bbiwmFQtlVveRcSys0Tf67xFjvQ4tqmWFgznClGDTXymyD8f6e2LNlAuuUXeEPS NKqjOc6yewnzHOMacLSvIfvoX0ZwxFLPvH6PvZOLhHWQbZJRNj5/+zlhVc/L9qimV8hg U7Ig== 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=Tm1Rrlzeiu2hYmomE6wgD9RmeVVX8cGTCCL6dvoZagg=; b=VVptK7KVNoMBgjFZK6iqFZEXFklVbMSdtg5eJ273y/B+HZwVSLH6E507nKFuvzBEp+ HbexngaVgxzYZoGv0v7/4eGkQ22QXduhDt6ykqT2v9tI+v2UxJ3G5B2eVIMVy+AXZwBo o+SodFaFPY2OgwM9INIIGpRiz8e/A5QqjIzppz5qlWdbTNG7BlnblBFdZvEzjBsQWS9t je9VhSMGvYjpe0+/G7ka/i5f/V/ccjR5Eq3R4IzBnuky6WeXMnMR+mfVLNm3MpJrjR0K 6bfIbbXpl946a9tviuvdbg8CErY6UH5fQYk2bmxi2HtSobtjiB7EiKlweizHYyjdys8N 5D9g== X-Gm-Message-State: AOAM5339BNJGFMF8G0nN7zmtsqSz6zhUWfs8Uh35CixQ3ZAMCSUklyZr sjpgjXIJbQ6ArMedfkcTND5mA0GoTODdl1j70sw= X-Google-Smtp-Source: ABdhPJwQI1fpG7ALdlXtVmAUhmS9hDXxxanSfd+9JMcxvX6Z+LpeHT8J4kbVUxcJipwltE0b+BrN3qza0GkgX09KkXo= X-Received: by 2002:a05:6602:2fcf:: with SMTP id v15mr20852674iow.78.1597857359897; Wed, 19 Aug 2020 10:15:59 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> <37dc1662-bcf5-8351-6ea7-5d8215e1b8d0@free.fr> <01AD8BB1-F40D-497B-948D-4C08A5155CCA@mit.edu> In-Reply-To: <01AD8BB1-F40D-497B-948D-4C08A5155CCA@mit.edu> From: Fabien Imbault Date: Wed, 19 Aug 2020 19:15:47 +0200 Message-ID: To: Justin Richer Cc: Dick Hardt , Francis Pouatcha , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000056a93c05ad3e28d7" Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Wed, 19 Aug 2020 17:16:04 -0000 --00000000000056a93c05ad3e28d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed. Le mer. 19 ao=C3=BBt 2020 =C3=A0 17:09, Justin Richer a = =C3=A9crit : > In my perspective, the focus should be on defining the protocol: what > you=E2=80=99d call the transaction pattern. We can potentially use a API = language > to describe how an entity can perform a role within that protocol, but > ultimately we should be defining the protocol. > > =E2=80=94 Justin > > On Aug 19, 2020, at 6:31 AM, Fabien Imbault > wrote: > > Just wondering if that might be a way to compose the generic > transaction/continuation pattern (XYZ style, layer 1) from a lower-level > GS-API (layer 0). > Fabien > > On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt wrote: > >> Hi Francis >> >> I have come to a similar conclusion. I'll be posting my thoughts in a >> concrete proposal and am keen to hear how it fits into how your mental >> model. >> >> /Dick >> =E1=90=A7 >> >> On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> wrote: >> >>> Lots of mails, so I will summarize my opinion in this single mail: >>> >>> We are dealing with different levels of abstraction here, this is why w= e >>> are always falling back to wording battles. >>> >>> oAuth2/OIDC vs. GNAP >>> AS vs. GS/DS/IS >>> Entity vs. Roles >>> User (human) vs. Requestor >>> Client vs (Orchestrator/Requesting Party/Negotiator...) >>> front-channel & back-channel >>> >>> To direct the discussion, we have to agree on the level of abstraction >>> at which we want a certain discussion to take place. >>> >>> Abstraction Level-0: GNAP >>> >>> Level-0 deals with roles (participants) and messages >>> (request/responses). Level-0 does not consider entities (users) or the >>> nature of any other participants, neither Level-0 deals with the way a >>> message is transported (synchronous/asynchronous) or the type of >>> interaction used to materialize the message (front-channel, back-channe= l). >>> The purpose of this abstraction layer is to provide a common understand= ing >>> of the core elements of the protocol. >>> >>> Level-0 can still provide some basic definition of messages including >>> information schema as long as we are not limiting the protocol with >>> constraints from lower layers. >>> >>> Level-0 is ideal to address some fundamental privacy and confidentialit= y >>> matters that will be materialized in lower layers. >>> >>> Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC] >>> Instantiation of Level-0 for a constrained application space. This is >>> why we will meet the world Client, User, RO, AS, .... here roles define= d in >>> Level-0 will be mapped to entities, interaction will be used to materia= lize >>> messages defined in Level-0. >>> The protocol mapping at this layer also takes into consideration that >>> some of those participants are human or only pieces of software, runnin= g on >>> the user device or on a server with consequences on the protocol design= . >>> >>> Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / .... >>> >>> In Summary: >>> Level-0: Roles, Messages >>> Level-1: Entities, Interactions >>> ... >>> >>> And if it happens we want to define GNAP at Level-1 (instead of 0), let >>> declare it as such and limit the application space before we proceed wi= th >>> further discussions. >>> >>> Best regards. >>> /Francis >>> >>> >>> >>> >>> On Thu, Aug 13, 2020 at 1:30 PM Denis wrote: >>> >>>> Justin, >>>> >>>> Your response does not address my point. I am talking of two different >>>> channels with the RS, i.e. not with the AS. >>>> >>>> Denis >>>> >>>> Denis, I want to focus on one point here: >>>> >>>> In OAuth 2.0, the user consent is performed by the AS using an >>>> authorize endpoint where the user consent is solicited and captured. >>>> >>>> Since a user, with no prior experience, shall first connect to a RS to >>>> perform an operation, the user consent shall be performed by the RS, >>>> instead of the AS. This means that we should define a "consent" >>>> endpoint at the RS. >>>> >>>> >>>> One of my goals with XYZ=E2=80=99s design was to be able to separate t= he >>>> interaction with the user from the web-based flows for the delegation >>>> protocol, and that aspect is enshrined in the GNAP charter as well. >>>> >>>> It points to the reality that there are two different aspects of the >>>> traditional AS that we might need to talk about separately now. One de= als >>>> with delegation, issuing tokens, returning data directly to the client= (not >>>> through a separate API, since that=E2=80=99s the RS), and other back-c= hannel stuff. >>>> The other aspect deals with interacting with the user and/or resource >>>> owner. >>>> >>>> We already saw bits of this in OAuth 2: the AS is defined by the pair >>>> of the token endpoint and authorization endpoint, each filling the >>>> respective roles above. What if we formally separate these? Strawman n= ames: >>>> >>>> Delegation Server (DS) - handles the back-channel stuff >>>> >>>> Interaction Server (IS) - handles the front-channel stuff >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> -- >>>> 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/ >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --00000000000056a93c05ad3e28d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Indeed.=C2=A0

      Le mer. 19 ao=C3=BBt 2020 =C3=A0 17:09, J= ustin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
      In my perspective, the focus should be on defining the proto= col: what you=E2=80=99d call the transaction pattern. We can potentially us= e a API language to describe how an entity can perform a role within that p= rotocol, but ultimately we should be defining the protocol.

      <= div>=C2=A0=E2=80=94 Justin

      On Au= g 19, 2020, at 6:31 AM, Fabien Imbault <fabien.imbault@= gmail.com> wrote:

      Just wondering if t= hat might be a way to compose the generic transaction/continuation pattern = (XYZ style, layer 1) from a lower-level GS-API (layer 0).
      Fabien
      <= /div>
      O= n Thu, Aug 13, 2020 at 9:28 PM Dick Hardt <dick.hardt@gmail= .com> wrote:
      Hi Francis

      I have=C2=A0come to a si= milar conclusion. I'll be posting my thoughts in a concrete proposal an= d am keen to hear how it fits into how your mental model.

      /Dick
      3D""= =E1=90=A7

      On Thu, Aug 13, 2020 at = 12:00 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.= ietf.org> wrote:
      Lots of mails, so I will summarize=C2=A0my opinion= in this single mail:

      We are dealing with different leve= ls of abstraction here, this is why we are always=C2=A0falling back to word= ing battles.

      oAuth2/OIDC vs. GNAP
      AS v= s. GS/DS/IS
      Entity vs. Roles
      User (human) vs. Reque= stor
      Client vs (Orchestrator/Requesting Party/Negotiator...)
      front-channel & back-channel

      = To direct the discussion, we have to agree on the level of abstraction at w= hich we want a certain discussion to take place.

      A= bstraction Level-0: GNAP

      Level-0 deals with roles = (participants) and messages (request/responses). Level-0 does not consider = entities (users) or the nature of any other participants,=C2=A0neither Leve= l-0 deals with the way a message is transported (synchronous/asynchronous) = or the type of interaction used to materialize the message (front-channel, = back-channel). The purpose of this abstraction layer is to provide a common= understanding of the core elements of the protocol.=C2=A0

      Level-0 can still provide some basic definition of messages includ= ing information schema as long as we are not limiting the protocol with con= straints from lower layers.

      Level-0 is ideal to ad= dress some fundamental privacy and confidentiality matters that will be mat= erialized in lower layers.

      Abstraction Level-1: OA= uth2 / OIDC / [SSI/DiD/VC]
      Instantiation of Level-0 for a constra= ined application space. This is why we will meet the world Client, User, RO= , AS, .... here roles defined in Level-0 will be mapped to entities, intera= ction will be used to materialize messages defined in Level-0.=C2=A0
      <= div>The protocol mapping at this layer also takes into consideration that s= ome of those participants are human or only pieces of software, running on = the user device or on a server with consequences on the protocol design.

      Abstraction Level-2: Trust Frameworks like IAM / PSD= 2,FAPI / ....

      In Summary:
      Level-0: Roles= , Messages
      Level-1: Entities, Interactions
      ...

      And if it happens we want to define GNAP at Level-1 (inste= ad of 0), let declare it as such and limit the application space before we = proceed with further discussions.

      Best regards.
      /Francis




      On= Thu, Aug 13, 2020 at 1:30 PM Denis <denis.ietf@free.fr&g= t; wrote:
      =20 =20 =20
      =C2=A0Justin,

      Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.

      Denis

      =20 Denis, I want to focus on one point here:

      In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

      Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
      instead of the AS. = This means that we should define a "consent" end= point at the RS.

      One of my goals with XYZ=E2=80=99s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

      It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that=E2=80=99s the RS), and other back-channel stuff. = The other aspect deals with interacting with the user and/or resource owner.=C2=A0

      We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

      Delegation Server (DS) - handles the back-channel stuff

      Interaction Server (IS) - handles the front-channel stuff


      =C2=A0=E2=80=94 Justin


      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/mailman/listi= nfo/txauth


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

      --00000000000056a93c05ad3e28d7-- From nobody Fri Aug 21 05:48:23 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 5DCAA3A0925 for ; Fri, 21 Aug 2020 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.997] autolearn=no autolearn_force=no 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 BT-qsoz2YW9h for ; Fri, 21 Aug 2020 05:48:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9E83A0924 for ; Fri, 21 Aug 2020 05:48:18 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d59 with ME id JCoC230052bcEcA03CoCQJ; Fri, 21 Aug 2020 14:48:16 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 21 Aug 2020 14:48:16 +0200 X-ME-IP: 90.79.51.120 To: Francis Pouatcha Cc: "txauth@ietf.org" From: Denis Message-ID: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> Date: Fri, 21 Aug 2020 14:48:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0AF33B6F985A865F5F831F21" Content-Language: en-GB Archived-At: Subject: [GNAP] About the use case called "Self sovereign identity (SSI)" 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: Fri, 21 Aug 2020 12:48:21 -0000 This is a multi-part message in MIME format. --------------0AF33B6F985A865F5F831F21 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Francis, This WG has not been formed to address SSI (Self sovereign identity). This use case can be solved without using an AS and a RS and without using a "Self Sovereign Identity (SSI)" approach. -Alice visits the website of AC-Tickets. -Alice looks up and finds "Bamberg Symphony", the concert she wants to attend. -Alice is informed that she can get a discount price if she is a resident of Bamberg. -Alice fills a form and enters the requested information.  She indicates that she is a resident of Bamberg and so she gets the discounted price. -Alice makes the payment using 3D secure. -Alice gets back a QR code on her phone that will be scanned when entering the concert hall. -Alice goes to the concert at Bamberg Symphony. -At the entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert,  her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only  for the residents of Bamberg. -If the person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,  she asks Alice to present her ID card or her passport which includes her home address and even more important her picture. ("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, as published in The New Yorker on July 5, 1993). This is simple, efficient and easy to implement right now. This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket . If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure that the individual is indeed over 60 but in addition the name on the identity card or the passport will be checked against the name on the railway ticket and that picture matches with the face of the person in front of the train controller. Anyway, IMHO, I don't believe that this use case should be solved using GNAP. Denis PS. This use case has been posted here: https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity --------------0AF33B6F985A865F5F831F21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Hello Francis,

      This WG has not been formed to address SSI (Self sovereign identity). This use case can be solved without using an AS and a RS
      and       without using a "Self Sovereign Identity (SSI)" approach.

      -          Alice visits the website of AC-Tickets.

      -          Alice looks up and finds "Bamberg Symphony", the concert she wants to attend.

      -          Alice is informed that she can get a discount price if she is a resident of Bamberg.

      -          Alice fills a form and enters the requested information.
       She indicates that she is a resident of Bamberg and so she gets the discounted price.

      -          Alice makes the payment using 3D secure.

      -          Alice gets back a QR code on her phone that will be scanned when entering the concert hall.

      -          Alice goes to the concert at Bamberg Symphony.

      -          At the entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert,
       her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only
       for the residents of Bamberg.

      -          If the person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,
       she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
      ("On the Internet, nobody knows you're a dog".       Peter Steiner's cartoon, as published in The New Yorker on July 5, 1993).

      This is simple, efficient and easy to implement right now.

      This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket .
      If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask
      the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
      that the individual is indeed over 60 but in addition the name on the       identity card or the passport will be checked against the name on the railway
      ticket and that picture matches with the face of the person in front of the train controller.

      Anyway, IMHO, I don't believe that this use case should be solved using GNAP.

      Denis

      PS. This use case has been posted here:
      https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity

      --------------0AF33B6F985A865F5F831F21-- From nobody Fri Aug 21 06:02:16 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 B5DB03A0962 for ; Fri, 21 Aug 2020 06:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UZpUBvhtQJLH for ; Fri, 21 Aug 2020 06:02:09 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854303A095E for ; Fri, 21 Aug 2020 06:02:09 -0700 (PDT) Received: from [192.168.1.11] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07LD23Xi004284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Aug 2020 09:02:04 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9734F5B3-020A-4C26-A01C-B0EE9620401E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 21 Aug 2020 09:02:03 -0400 In-Reply-To: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> Cc: Francis Pouatcha , "txauth@ietf.org" To: Denis References: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] About the use case called "Self sovereign identity (SSI)" 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: Fri, 21 Aug 2020 13:02:12 -0000 --Apple-Mail=_9734F5B3-020A-4C26-A01C-B0EE9620401E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The SSI trick is not the ticket =E2=80=94 the SSI portion here is "She = indicates that she is a resident of Bamberg=E2=80=9D. We=E2=80=99d like = Alice to be able to do that in a verifiable and programatic way that we = can enable in the protocol flow. =E2=80=94 Justin > On Aug 21, 2020, at 8:48 AM, Denis wrote: >=20 >=20 > Hello Francis, > This WG has not been formed to address SSI (Self sovereign identity). = This use case can be solved without using an AS and a RS=20 > and without using a "Self Sovereign Identity (SSI)" approach. >=20 > - Alice visits the website of AC-Tickets. >=20 > - Alice looks up and finds "Bamberg Symphony", the concert = she wants to attend. >=20 > - Alice is informed that she can get a discount price if she = is a resident of Bamberg. >=20 > - Alice fills a form and enters the requested information.=20 > She indicates that she is a resident of Bamberg and so she gets the = discounted price. >=20 > - Alice makes the payment using 3D secure. >=20 > - Alice gets back a QR code on her phone that will be scanned = when entering the concert hall. >=20 > - Alice goes to the concert at Bamberg Symphony. >=20 > - At the entrance gate, Alice presents her QR code which = includes a unique identifier for this concert, the date and time of the = concert,=20 > her seat number reservation, her family name and her first name and = the fact that the ticket price is a discounted price available only=20 > for the residents of Bamberg. >=20 > - If the person controlling the QR-codes at the gate has some = doubt that Alice is indeed a resident of Bamberg,=20 > she asks Alice to present her ID card or her passport which includes = her home address and even more important her picture. > ("On the Internet, nobody knows you're a dog". Peter Steiner's = cartoon, as published in The New Yorker on July 5, 1993). >=20 > This is simple, efficient and easy to implement right now.=20 >=20 > This is roughly how train reservations are working on the French web = site oui.sncf. Some one over 60 can request a discounted railway ticket = .=20 > If the train controller has some doubt that the bearer of the = discounted railway ticket is really over 60 after scanning the QR code, = he will ask=20 > the person to show an identity card or a passport at the platform = entrance or while in the train. Not only the year of birth will allow to = make sure > that the individual is indeed over 60 but in addition the name on the = identity card or the passport will be checked against the name on the = railway=20 > ticket and that picture matches with the face of the person in front = of the train controller. >=20 > Anyway, IMHO, I don't believe that this use case should be solved = using GNAP.=20 >=20 > Denis=20 >=20 > PS. This use case has been posted here:=20 > = https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchas= ing-a-concert-ticket-without-disclosing-her-identity = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_9734F5B3-020A-4C26-A01C-B0EE9620401E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
      The SSI trick is not the ticket = =E2=80=94 the SSI portion here is "She indicates that she is a resident of = Bamberg=E2=80=9D.= We=E2=80=99d like Alice to be able to do that in a verifiable and = programatic way that we can enable in the protocol = flow.

       =E2=80=94 = Justin

      On Aug 21, 2020, at 8:48 AM, Denis <denis.ietf@free.fr> = wrote:

      =20

      Hello Francis,

      This WG has not been formed = to address SSI (Self sovereign identity). This use case = can be solved without = using an AS and a RS
      and       without using a "Self = Sovereign Identity (SSI)" = approach.

      -          Alice visits the website of = AC-Tickets.

      -          Alice looks up and finds = "Bamberg Symphony", the concert she wants to attend.

      -          Alice is informed that she can = get a discount price if she is a resident of Bamberg.

      -          Alice fills a form and enters = the requested information.
       She indicates that she is a resident of Bamberg and so she gets the discounted price.

      -          Alice makes the payment using = 3D secure.

      -          Alice gets back a QR code on = her phone that will be scanned when entering the concert hall.

      -          Alice goes to the concert at = Bamberg Symphony.

      -          At the entrance gate, Alice = presents her QR code which includes a unique identifier for this concert, the date and time of the concert, =
       her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only
       for the residents of Bamberg.

      -          If the person controlling the = QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,
       she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
      ("On the Internet, nobody knows you're a dog".       Peter Steiner's cartoon, as = published in The New Yorker on July 5, 1993).

      This is simple, efficient and = easy to implement right now.

      This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket .
      If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask
      the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
      that the individual is indeed over 60 but in addition the name on the       identity card or the = passport will be checked against the name on the railway
      ticket and that picture matches with the face of the person in front of the train controller.

      Anyway, IMHO, I don't believe = that this use case should be solved using GNAP.

      Denis

      PS. This use case has been posted = here:
      https://gith= ub.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concer= t-ticket-without-disclosing-her-identity

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

      = --Apple-Mail=_9734F5B3-020A-4C26-A01C-B0EE9620401E-- From nobody Fri Aug 21 06:09:17 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 851D83A07FF for ; Fri, 21 Aug 2020 06:09:14 -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 rQWu2HYiMH6c for ; Fri, 21 Aug 2020 06:09:12 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 5B8E63A058F for ; Fri, 21 Aug 2020 06:09:12 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a5so1886542wrm.6 for ; Fri, 21 Aug 2020 06:09:12 -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=0IxexUXFix9Np6rnhex4RQWiSrceT4V173Mz+dPEmqw=; b=ECXldXq/rbcou8Ilib9eMSBI9k9r60kPjtD95skenrL3RRedNsKUurRog1ONZxOMDw 3pz0TVgA/8QFnf6Fb85ExLQ6YpS5gG7sFEIdXPkawbluZmnUI1Le6IRFHsrDDV7rwFWC PnZx5AHP6kbe06LPn1dRv5zAaNcgxfEzNaXBw= 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=0IxexUXFix9Np6rnhex4RQWiSrceT4V173Mz+dPEmqw=; b=t04FeKlKiW8Kxo2olGD8YWCinHUeL/eFW/bEWmbxlzW+xS58WnDWKZ2mR9P2xY9I/W TMoT8HlItr/d94x8Dp42Y7bzK3nmjNzPzDnO7AiMTpPmaIK1DGw4Ie35gixVqQsNC9Xq y0crY7OBso0V91QNEa5to96yu/nv/Xytnt593XgoVbjufv5seqVU1Y38LwJ/0ZwDvdFc aNesMi9O12VyyqpxtscPTIHr4tmek6bF+A1ati4UlLOfSlijAuGJaG5L8WQOWOi41Cfq 5qREf6OTDqQF/RSUVBLdcYiXij88ezVop16NUhbzhlPMCt3jkQqk9eRa671g/8Do4cNz RXpA== X-Gm-Message-State: AOAM5301Aq8yXdqOeuonbeiqLArKQoyo/B1waYqxdUNRt/ZvUmEuBCTv 9pG7ZZiS/cq9vyZTuXnyWC9oYUbeF1abeN0zNFBWwA== X-Google-Smtp-Source: ABdhPJyE/DsESti79kgRnLwiWCOJsAC6Pv6ceDJ0iT0VtgFZSiih9BHPJmP6iaoq/uBVbYgYi7Odu2W8U2wzxiqmGe8= X-Received: by 2002:adf:cc88:: with SMTP id p8mr2646787wrj.70.1598015350325; Fri, 21 Aug 2020 06:09:10 -0700 (PDT) MIME-Version: 1.0 References: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> In-Reply-To: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> From: Francis Pouatcha Date: Fri, 21 Aug 2020 09:08:59 -0400 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004d5e7605ad62f1fb" Archived-At: Subject: Re: [GNAP] About the use case called "Self sovereign identity (SSI)" 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: Fri, 21 Aug 2020 13:09:15 -0000 --0000000000004d5e7605ad62f1fb Content-Type: text/plain; charset="UTF-8" Hello Denis, in your use case description, - the RS ist the concert gateman - now AS/GS is AC-Tickets - AS/GS issue a conditioned token (Please allow Alice to this concert only if she is older than 18 and a resident of Bamberg) - Human RS is given an "option" to check these claims at the gate (or not). - Check is negative: Alice is younger than 18, but has bought a concert ticket from the ticket website (legal contract). Who is liable? Best regards /Francis On Fri, Aug 21, 2020 at 8:48 AM Denis wrote: > Hello Francis, > > This WG has not been formed to address SSI (Self sovereign identity). This > use case can be solved without using an AS and a RS > and without using a "Self Sovereign Identity (SSI)" approach. > > - Alice visits the website of AC-Tickets. > > - Alice looks up and finds "Bamberg Symphony", the concert she > wants to attend. > > - Alice is informed that she can get a discount price if she is > a resident of Bamberg. > > - Alice fills a form and enters the requested information. > She indicates that she is a resident of Bamberg and so she gets the > discounted price. > > - Alice makes the payment using 3D secure. > > - Alice gets back a QR code on her phone that will be scanned > when entering the concert hall. > > - Alice goes to the concert at Bamberg Symphony. > > - At the entrance gate, Alice presents her QR code which > includes a unique identifier for this concert, the date and time of the > concert, > her seat number reservation, her family name and her first name and the > fact that the ticket price is a discounted price available only > for the residents of Bamberg. > > - If the person controlling the QR-codes at the gate has some > doubt that Alice is indeed a resident of Bamberg, > she asks Alice to present her ID card or her passport which includes her > home address and even more important her picture. > ("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, > as published in The New Yorker on July 5, 1993). > > This is simple, efficient and easy to implement right now. > > This is roughly how train reservations are working on the French web site > oui.sncf. Some one over 60 can request a discounted railway ticket . > If the train controller has some doubt that the bearer of the discounted > railway ticket is really over 60 after scanning the QR code, he will ask > the person to show an identity card or a passport at the platform entrance > or while in the train. Not only the year of birth will allow to make sure > that the individual is indeed over 60 but in addition the name on the identity > card or the passport will be checked against the name on the railway > ticket and that picture matches with the face of the person in front of > the train controller. > > Anyway, IMHO, I don't believe that this use case should be solved using > GNAP. > > Denis > > PS. This use case has been posted here: > > https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity > > -- Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --0000000000004d5e7605ad62f1fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hello Denis,

      in your use case descripti= on,
      - the RS ist the concert gateman
      - now AS/GS is=C2= =A0AC-Tickets

      =
      - AS/GS issue a conditioned token (Please allow Alice to this concert = only if she is older than 18 and a resident of Bamberg)
      - Human R= S is given an=C2=A0"option" to check these claims at the gate (or= not).

      - Check is negative: Alice is younger than = 18, but has bought a concert ticket from the ticket website (legal contract= ). Who is liable?

      Best regards
      /Francis<= /div>

      On Fri, Aug 21, 2020 at 8:48 AM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20

      Hello Francis,

      This WG has not been formed to address SSI (Self sovereign identity). This use case = can be solved without us= ing an AS and a RS
      and       without using a "Self Sovereign Identity (SSI)" approach.<= span style=3D"font-family:Arial" lang=3D"EN-US">

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e visits the website of AC-Tickets.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e looks up and finds "Bamberg Symphony", the concert she wants to attend.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e is informed that she can get a discount price if she is a resident of Bamberg.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e fills a form and enters the requested information.
      =C2=A0She indicates that she is a resident of Bamberg and so she gets the discounted price.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e makes the payment using 3D secure.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e gets back a QR code on her phone that will be scanned when entering the concert hall.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Alic= e goes to the concert at Bamberg Symphony.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 At t= he entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert,
      =C2=A0her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only
      =C2=A0for the residents of Bamberg.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 If t= he person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,
      =C2=A0she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
      ("On the Internet, nobody knows you're a dog". Peter Steiner's carto= on, as published in The New Yorker = on July 5, 1993).

      This is simple, efficient and easy to implement right now.

      This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket .
      If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask
      the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
      that the individual is indeed over 60 but in addition the name on the       identity card or the passport will be checked against the name on the railway
      ticket and that picture matches with the face of the person in front of the train controller.

      Anyway, IMHO, I don't believe that this use case should be solved using GNAP.

      Denis

      PS. This use case has bee= n posted here:
      https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-p= urchasing-a-concert-ticket-without-disclosing-her-identity



      --
      Francis Pouatcha
      Co-= Founder and Technical Lead
      adorsys GmbH & Co. KG
      https://= adorsys-platform.de/solutions/
      --0000000000004d5e7605ad62f1fb-- From nobody Fri Aug 21 06:14:44 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 CF7F63A0805 for ; Fri, 21 Aug 2020 06:14:42 -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 JFSZ5axn1Hxi for ; Fri, 21 Aug 2020 06:14:41 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 E6EA83A040F for ; Fri, 21 Aug 2020 06:14:40 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id t14so1788429wmi.3 for ; Fri, 21 Aug 2020 06:14:40 -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=c+BU8IRUTIr5Bws7aWOasJ0KbB8epbQXri6xnzLX8XY=; b=RHPUVFTdQ687sBYr8Pa00ezHY2DHM/gsu6juYZrGsv1T2FbEtSj262wR3GqeQM7CN2 jpSxnmMBFKqge2kujn4HI3LYE0/VO/C9HBDmtLTu3rg8FVwCljRhpkmRwUNpQpBgQroB hJV+nMN67Uf4l9VJC74sadECAlFfew0JQHQc4= 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=c+BU8IRUTIr5Bws7aWOasJ0KbB8epbQXri6xnzLX8XY=; b=QH32JELQyJsot4FY3ItCNt5qciiRl/NZBItqlY8avaxjfZf1d2+2mEMvxLSFIe9FOK aZkFisVR+1idt6jaWhilvzs/2CwzgKbTZnNtRX23/KFz26PpxHNa1Ap5Z6ssrkn++L+B ez0qds8pr5CfAxpS1/hb/yk0jbsnVClY9nQGwOPZaNW1dISNUi2FH+87agFaXh8a36Q8 +UtTCy3AMPXTgYGxpIVRP9xowZWOffLa5S3hTouOLe6vmQTRT69L0I4gyTzDIfvB9YgC MxCN7OqZj3Zye7n/tlpP8lpHqondcQ2IonZ/kOlWPKlVQKLFa0QYpPUHRlKoKIOnX+Nl QD3g== X-Gm-Message-State: AOAM5307CvDDc2ifxbcELjkqV7EvUMOPsi3CbxmuePTUk0VvMUlse60H c5DYKEvUCU0iLM7UQFh5u+rZf2hOJsmA7XScrj6K6g== X-Google-Smtp-Source: ABdhPJyJlQXWTFNyGWWKUA8QSVZYR3kXfhz+9lOaA3uRcnQSbBOvBi4kcuHnL90dcyLHnOlfEz1mOeov9kn49GadeBk= X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr3721939wmj.8.1598015678910; Fri, 21 Aug 2020 06:14:38 -0700 (PDT) MIME-Version: 1.0 References: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> In-Reply-To: From: Francis Pouatcha Date: Fri, 21 Aug 2020 09:14:27 -0400 Message-ID: To: Justin Richer Cc: Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e36ede05ad63043e" Archived-At: Subject: Re: [GNAP] About the use case called "Self sovereign identity (SSI)" 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: Fri, 21 Aug 2020 13:14:43 -0000 --000000000000e36ede05ad63043e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2020 at 9:02 AM Justin Richer wrote: > The SSI trick is not the ticket =E2=80=94 the SSI portion here is "She in= dicates > that she is a resident of Bamberg=E2=80=9D. We=E2=80=99d like Alice to be= able to do that > in a verifiable and programatic way that we can enable in the protocol fl= ow. > Yes. The purpose of SSI in this use case is to illustrate that authz flows will have many claim origins. Flows will have many situations where GS relies on claims produced/presented by other ASs for a compound Authz decision. Best regards /Francis > > =E2=80=94 Justin > > On Aug 21, 2020, at 8:48 AM, Denis wrote: > > > Hello Francis, > > This WG has not been formed to address SSI (Self sovereign identity). Thi= s > use case can be solved without using an AS and a RS > and without using a "Self Sovereign Identity (SSI)" approach. > > - Alice visits the website of AC-Tickets. > > - Alice looks up and finds "Bamberg Symphony", the concert she > wants to attend. > > - Alice is informed that she can get a discount price if she is > a resident of Bamberg. > > - Alice fills a form and enters the requested information. > She indicates that she is a resident of Bamberg and so she gets the > discounted price. > > - Alice makes the payment using 3D secure. > > - Alice gets back a QR code on her phone that will be scanned > when entering the concert hall. > > - Alice goes to the concert at Bamberg Symphony. > > - At the entrance gate, Alice presents her QR code which > includes a unique identifier for this concert, the date and time of the > concert, > her seat number reservation, her family name and her first name and the > fact that the ticket price is a discounted price available only > for the residents of Bamberg. > > - If the person controlling the QR-codes at the gate has some > doubt that Alice is indeed a resident of Bamberg, > she asks Alice to present her ID card or her passport which includes her > home address and even more important her picture. > ("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, > as published in The New Yorker on July 5, 1993). > > This is simple, efficient and easy to implement right now. > > This is roughly how train reservations are working on the French web site > oui.sncf. Some one over 60 can request a discounted railway ticket . > If the train controller has some doubt that the bearer of the discounted > railway ticket is really over 60 after scanning the QR code, he will ask > the person to show an identity card or a passport at the platform entranc= e > or while in the train. Not only the year of birth will allow to make sure > that the individual is indeed over 60 but in addition the name on the ide= ntity > card or the passport will be checked against the name on the railway > ticket and that picture matches with the face of the person in front of > the train controller. > > Anyway, IMHO, I don't believe that this use case should be solved using > GNAP. > > Denis > > PS. This use case has been posted here: > > https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purcha= sing-a-concert-ticket-without-disclosing-her-identity > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --=20 Francis Pouatcha Co-Founder and Technical Lead adorsys GmbH & Co. KG https://adorsys-platform.de/solutions/ --000000000000e36ede05ad63043e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

      On Fri, Aug 21, 2020 at 9:02 AM Justin Ri= cher <jricher@mit.edu> wrote:<= br>
      The SSI trick is not the ticket =E2=80=94 th= e SSI portion here is "She indicates= that she is a resident of Bamberg=E2=80= =9D. We=E2=80=99d like Alice to be= able to do that in a verifiable and programatic way that we can enable in = the protocol flow.
      Yes.=C2=A0
      The purpose of SSI in this use case is to illustrate that authz flo= ws will have many claim origins. Flows will have many situations where GS r= elies on claims produced/presented by other ASs for a compound Authz decisi= on.=C2=A0
      Best regards
      /Francis
      =

      =C2=A0=E2=80=94 Justin

      On Aug 21, 2020, at 8:48 AM, Denis <denis.ietf@free.fr> wrote:
      =20

      Hello Francis,<= p class=3D"MsoNormal">This WG has not been formed to address SSI (Self sovereign identity). This use case = can be solved without us= ing an AS and a RS
      and       without using a "Self Sovereign Identity (SSI)" approach.<= span style=3D"font-family:Arial" lang=3D"EN-US">

      -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e visits the website of AC-Tickets.

      <= p class=3D"MsoNormal" style=3D"margin-left:36pt">-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Alic= e looks up and finds "Bamberg Symphony", the concert she wants to attend.

      -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e is informed that she can get a discount price if she is a resident of Bamberg.

      -=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e fills a form and enters the requested information.
      =C2=A0She indicates that she is a resident of Bamberg and so she gets the discounted price.

      = -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e makes the payment using 3D secure.

      -<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e gets back a QR code on her phone that will be scanned when entering the concert hall.

      -<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e goes to the concert at Bamberg Symphony.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 At t= he entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert,
      =C2=A0her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only
      =C2=A0for the residents of Bamberg.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If t= he person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,
      =C2=A0she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
      ("On the Internet, nobody knows you're a dog". Peter Steiner's carto= on, as published in The New Yorker = on July 5, 1993).

      This is simple, efficient and easy to implement right now.

      This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket .
      If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask
      the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
      that the individual is indeed over 60 but in addition the name on the       identity card or the passport will be checked against the name on the railway
      ticket and that picture matches with the face of the person in front of the train controller.

      Anyway, IMHO, I don't bel= ieve that this use case should be solved using GNAP.

      Denis

      PS. This use= case has been posted here:
      https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-p= urchasing-a-concert-ticket-without-disclosing-her-identity

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



      --
      Francis Pouatcha
      Co-Founder and Technical Lead
      =
      adorsys GmbH & Co. KG
      --000000000000e36ede05ad63043e-- From nobody Fri Aug 21 06:39:57 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 7CB203A0744 for ; Fri, 21 Aug 2020 06:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 kjDj37RV89TI for ; Fri, 21 Aug 2020 06:39:53 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 9E6FF3A0849 for ; Fri, 21 Aug 2020 06:39:53 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id s1so1710032iot.10 for ; Fri, 21 Aug 2020 06:39:53 -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=k/5IQbWip9a5ryE7wLLEeZveYJhtIrGeToCYEVERWuk=; b=YkGX7YvT1Qd2+7a2zUCa/XCTa8av1Ut9QG3j2Pi3tOZpm0zuRmbyPo4JpU5ijPElYl Tu5SBSc4M0tkBKRMGqPQew+up+rhqewceD4zDBoTLQdpFUxkTf494KMRDIK+sgMCOkw7 i9hCOG1y+nSsDIWzKV1FKraVqyXbSPaXCVR4ZUZDucvLp1SllGCh5+21anmnmffyO0hA 10/3gczdkiEqINAWj+HcKkwORjn8jWyBbft2+uMfv8hTem7wgyEmQwVpY7ZykkeVI22n CXLUesPx6CikrQwycxIrV9ZwbnjmGTx6m0ZpIDR8l/SUSKbl3lhBC0TmL8XXy6fcmWSb PaHg== 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=k/5IQbWip9a5ryE7wLLEeZveYJhtIrGeToCYEVERWuk=; b=HF4k/SdJllljMeX4jJFoe6JPQESYU8XPKHalDDaNCFdRc0EbwQkhMUf9d3VaKCSa/Q YY3nL+z/cmfIvKucasIjnjraeufn8L4qNLSzFSo5t8aSiX+qTp4VNKhqi9ddDQd9UNXW WErrMHMuX6NOJswKTjup5zM9A8fvnve1eEyIEinIOBPVSVPE4Z5ZhSVyMlorG2hC+DHo 3Xiq4Vqle0qOEdo8v9m6f33eAhhHCyZ7U+3Tn8qkY7a6GwK2iePF8QQnxXHU5BVnxbb2 mMAT8vPri86KV27Zi4ldH8jF8WSVLNjXsPzNvwIMFMUWgsBK6y7L9gBMy+owCBD1/fif G1iA== X-Gm-Message-State: AOAM532PLO2TAjuxYUvvkY5v8pG/SMWoF4MwnLHQMoreL9ZObE7XA3Yr MGMJ5UC8T6tKR8/Ob/9SseDUSkzUDOi56jrKi0I= X-Google-Smtp-Source: ABdhPJzIV9Rk7X+5xbQ0xL+OS8/opGBJ4qoEiTyMs0VmzW9FvkSj97r1kP4KoXZKA3ZB7wucYH4y/zK+JoLQADLrzS4= X-Received: by 2002:a02:7092:: with SMTP id f140mr2743771jac.8.1598017192628; Fri, 21 Aug 2020 06:39:52 -0700 (PDT) MIME-Version: 1.0 References: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> In-Reply-To: From: Fabien Imbault Date: Fri, 21 Aug 2020 15:39:38 +0200 Message-ID: To: Francis Pouatcha Cc: Justin Richer , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001c9d5705ad635f67" Archived-At: Subject: Re: [GNAP] About the use case called "Self sovereign identity (SSI)" 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: Fri, 21 Aug 2020 13:39:56 -0000 --0000000000001c9d5705ad635f67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The use case is a bit complex (payment, etc.), but I think there are 2 important items in relation to SSI : - it is interesting to integrate just like it is with OIDC or FIDO for instance, SSI is now part of the ecosystem (ex: DID Auth / SIOP is considered by openid) - you get the ability to handle somes cases better with verified credentials (which the example illustrates: it's better to confidently check the age before you even issue the token). "On the Internet, nobody knows you're a dog" -> maybe not any more (at least if the issuer wants to keep his reputation intact). Btw it helps for privacy too (zkp). Of course, one can still use GNAP or SSI separately (This use case can be solved without using an AS and a RS -> maybe but it can also be solved with AS and RS). And I don't think it changes the core design of what we're discussing. Fabien On Fri, Aug 21, 2020 at 3:14 PM Francis Pouatcha wrote: > > On Fri, Aug 21, 2020 at 9:02 AM Justin Richer wrote: > >> The SSI trick is not the ticket =E2=80=94 the SSI portion here is "She i= ndicates >> that she is a resident of Bamberg=E2=80=9D. We=E2=80=99d like Alice to b= e able to do >> that in a verifiable and programatic way that we can enable in the proto= col >> flow. >> > Yes. > The purpose of SSI in this use case is to illustrate that authz flows wil= l > have many claim origins. Flows will have many situations where GS relies = on > claims produced/presented by other ASs for a compound Authz decision. > Best regards > /Francis > >> >> =E2=80=94 Justin >> >> On Aug 21, 2020, at 8:48 AM, Denis wrote: >> >> >> Hello Francis, >> >> This WG has not been formed to address SSI (Self sovereign identity). >> This use case can be solved without using an AS and a RS >> and without using a "Self Sovereign Identity (SSI)" approach. >> >> - Alice visits the website of AC-Tickets. >> >> - Alice looks up and finds "Bamberg Symphony", the concert she >> wants to attend. >> >> - Alice is informed that she can get a discount price if she is >> a resident of Bamberg. >> >> - Alice fills a form and enters the requested information. >> She indicates that she is a resident of Bamberg and so she gets the >> discounted price. >> >> - Alice makes the payment using 3D secure. >> >> - Alice gets back a QR code on her phone that will be scanned >> when entering the concert hall. >> >> - Alice goes to the concert at Bamberg Symphony. >> >> - At the entrance gate, Alice presents her QR code which >> includes a unique identifier for this concert, the date and time of the >> concert, >> her seat number reservation, her family name and her first name and the >> fact that the ticket price is a discounted price available only >> for the residents of Bamberg. >> >> - If the person controlling the QR-codes at the gate has some >> doubt that Alice is indeed a resident of Bamberg, >> she asks Alice to present her ID card or her passport which includes he= r >> home address and even more important her picture. >> ("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, >> as published in The New Yorker on July 5, 1993). >> >> This is simple, efficient and easy to implement right now. >> >> This is roughly how train reservations are working on the French web sit= e >> oui.sncf. Some one over 60 can request a discounted railway ticket . >> If the train controller has some doubt that the bearer of the discounted >> railway ticket is really over 60 after scanning the QR code, he will ask >> the person to show an identity card or a passport at the platform >> entrance or while in the train. Not only the year of birth will allow to >> make sure >> that the individual is indeed over 60 but in addition the name on the id= entity >> card or the passport will be checked against the name on the railway >> ticket and that picture matches with the face of the person in front of >> the train controller. >> >> Anyway, IMHO, I don't believe that this use case should be solved using >> GNAP. >> >> Denis >> >> PS. This use case has been posted here: >> >> https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purch= asing-a-concert-ticket-without-disclosing-her-identity >> >> -- >> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001c9d5705ad635f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable       --0000000000001c9d5705ad635f67-- From nobody Fri Aug 21 06:44:48 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 295CB3A045B for ; Fri, 21 Aug 2020 06:44:47 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hindleconsulting.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 6HwT5yMV5VFe for ; Fri, 21 Aug 2020 06:44:44 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 215223A0406 for ; Fri, 21 Aug 2020 06:44:43 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id q9so1592973oth.5 for ; Fri, 21 Aug 2020 06:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hindleconsulting.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sgunhW3dcNvh+DuyJGgmLqyH+AlchT61ta4ZtDJFVDg=; b=U3m+4M36AgeY6b3wCNItCYyDMvdnw3Li850WOJqFg5zQ9gTimO64iMR4zchc8W6hbs UcUYii16v6OTOfIspKX7/55SBQoW/SbCguuKLEIFZqHZaStLtZW8/NBuYTk7qa47ogNx npwgDhMAnOrXHSDClqkeP+kgIZwNvw85e+xQA= 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=sgunhW3dcNvh+DuyJGgmLqyH+AlchT61ta4ZtDJFVDg=; b=EcczmlKheWyT0RZI0uG1L4/sysAb1eZPDfEsu7p3ExjOffrS4T3f+OPjQPhI49K6XF x9r3Js6cIjQU775zkBDZL+DIkVDLyOftmmbtfo1hNHKGiIZicIOalPQnDFWIlrwW5Yeq JyVJ8V8ylviqD927aWukJWBAxQjOHzmzGJ47Rnvr11axBdW6wtVJKnvMKhEu0ZmhyEUH pkJimz3Nsa2oo/RZh2qtNhbp5MSXC3XwDOFSAHv9g8WNBqkcaxbc3BPGAcIToXUJZqYf ndC1YY2qcG0OrhlrGBr1IIKj1qVwcY2UoZMUih8wwiRxkct4kLgwcKT/rxeeSDb1gZG0 FQiA== X-Gm-Message-State: AOAM532I5OtFpjteafJmskdgyUAJjVlZphbnwHrdcMqQHa0Z7W9eKJ3G eUdLikjtVWzSBOO1sGyNICv0AhbrXUPaCull5LemM4BHh9vLIkzroU4vpJvzNmvChrhET5n3Lxq LDr83glAzvOF0JIDH X-Google-Smtp-Source: ABdhPJyejDRC/l4lmsLXaKWVJmnVhvRvHS5zjnb8FUaCEsjhG8MfQ9jCDzeCWBKYUCZZWK9Iqay5tlP5AYjwF327hXU= X-Received: by 2002:a9d:73ce:: with SMTP id m14mr1906661otk.265.1598017482904; Fri, 21 Aug 2020 06:44:42 -0700 (PDT) MIME-Version: 1.0 References: <84df3d97-841d-5dea-477b-465866bcffaa@free.fr> In-Reply-To: From: Andrew Hindle Date: Fri, 21 Aug 2020 14:44:31 +0100 Message-ID: To: Francis Pouatcha Cc: Justin Richer , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000069e9f505ad6370a3" Archived-At: Subject: Re: [GNAP] About the use case called "Self sovereign identity (SSI)" 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: Fri, 21 Aug 2020 13:44:47 -0000 --00000000000069e9f505ad6370a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, in the UMA WG some time ago we explored (at a conceptual level) how the concept of SSI could/should intersect with the UMA protocol flow. It's an important consideration, exactly for the reasons that Francis outlines. There are plenty of use-cases that are well solved without SSI (and, indeed, without any need for 'verified' or 'attested' attributes per se). But there are also some very important use-cases where this kind of integration will be important. I think it's smart to consider this in the GNAP specification design. --&e On Fri, 21 Aug 2020 at 14:14, Francis Pouatcha wrote: > > On Fri, Aug 21, 2020 at 9:02 AM Justin Richer wrote: > >> The SSI trick is not the ticket =E2=80=94 the SSI portion here is "She i= ndicates >> that she is a resident of Bamberg=E2=80=9D. We=E2=80=99d like Alice to b= e able to do >> that in a verifiable and programatic way that we can enable in the proto= col >> flow. >> > Yes. > The purpose of SSI in this use case is to illustrate that authz flows wil= l > have many claim origins. Flows will have many situations where GS relies = on > claims produced/presented by other ASs for a compound Authz decision. > Best regards > /Francis > >> >> =E2=80=94 Justin >> >> On Aug 21, 2020, at 8:48 AM, Denis wrote: >> >> >> Hello Francis, >> >> This WG has not been formed to address SSI (Self sovereign identity). >> This use case can be solved without using an AS and a RS >> and without using a "Self Sovereign Identity (SSI)" approach. >> >> - Alice visits the website of AC-Tickets. >> >> - Alice looks up and finds "Bamberg Symphony", the concert she >> wants to attend. >> >> - Alice is informed that she can get a discount price if she is >> a resident of Bamberg. >> >> - Alice fills a form and enters the requested information. >> She indicates that she is a resident of Bamberg and so she gets the >> discounted price. >> >> - Alice makes the payment using 3D secure. >> >> - Alice gets back a QR code on her phone that will be scanned >> when entering the concert hall. >> >> - Alice goes to the concert at Bamberg Symphony. >> >> - At the entrance gate, Alice presents her QR code which >> includes a unique identifier for this concert, the date and time of the >> concert, >> her seat number reservation, her family name and her first name and the >> fact that the ticket price is a discounted price available only >> for the residents of Bamberg. >> >> - If the person controlling the QR-codes at the gate has some >> doubt that Alice is indeed a resident of Bamberg, >> she asks Alice to present her ID card or her passport which includes he= r >> home address and even more important her picture. >> ("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, >> as published in The New Yorker on July 5, 1993). >> >> This is simple, efficient and easy to implement right now. >> >> This is roughly how train reservations are working on the French web sit= e >> oui.sncf. Some one over 60 can request a discounted railway ticket . >> If the train controller has some doubt that the bearer of the discounted >> railway ticket is really over 60 after scanning the QR code, he will ask >> the person to show an identity card or a passport at the platform >> entrance or while in the train. Not only the year of birth will allow to >> make sure >> that the individual is indeed over 60 but in addition the name on the id= entity >> card or the passport will be checked against the name on the railway >> ticket and that picture matches with the face of the person in front of >> the train controller. >> >> Anyway, IMHO, I don't believe that this use case should be solved using >> GNAP. >> >> Denis >> >> PS. This use case has been posted here: >> >> https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purch= asing-a-concert-ticket-without-disclosing-her-identity >> >> -- >> 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/ > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Andrew Hindle; CIPM , CIPP/E , CIPT Hindle Consulting Limited +44 7966 136543 Schedule a meeting --=20 Hindle Consulting Limited is a company registered in England and Wales. =C2= =A0 Company number: 8888564. Registered office: Claremont House, 1 Market=20 Square, Bicester, Oxfordshire OX26 6AA, UK. --00000000000069e9f505ad6370a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      FWIW, in the UMA WG some time ago we explored (at a concep= tual level) how the concept of SSI could/should intersect with the UMA prot= ocol flow.
      It's an important consideration, exactly for the reasons= that Francis outlines.=C2=A0 There are plenty of use-cases that are well s= olved without SSI (and, indeed, without any need for 'verified' or = 'attested' attributes per se).=C2=A0 But there are also some very i= mportant use-cases where this kind of integration will be important.
      <= div>I think it's smart to consider this in the GNAP specification desig= n.
      --&e



      On Fri, 21 Aug 202= 0 at 14:14, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

      On Fri, Aug 21, 2020 at 9:02 AM Just= in Richer <jricher@= mit.edu> wrote:
      The SSI trick is= not the ticket =E2=80=94 the SSI portion here is "She indicates that she is a resident of Bamberg= =E2=80=9D. We= =E2=80=99d like Alice to be able to do that in a verifiable and programatic= way that we can enable in the protocol flow.
      Yes.=C2=A0
      The purpose of SSI in this use case is t= o illustrate that authz flows will have many claim origins. Flows will have= many situations where GS relies on claims produced/presented by other ASs = for a compound Authz decision.=C2=A0
      Best regards
      /Fran= cis

      <= /span>
      =C2=A0=E2=80=94 Justin

      On Aug 21, 2020, at 8:48= AM, Denis <deni= s.ietf@free.fr> wrote:

      =20

      Hello Francis,<= p class=3D"MsoNormal">This WG has not been formed to address SSI (Self sovereign identity). This use case = can be solved without us= ing an AS and a RS
      and       without using a "Self Sovereign Identity (SSI)" approach.<= span style=3D"font-family:Arial" lang=3D"EN-US">

      -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e visits the website of AC-Tickets.

      <= p class=3D"MsoNormal" style=3D"margin-left:36pt">-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Alic= e looks up and finds "Bamberg Symphony", the concert she wants to attend.

      -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e is informed that she can get a discount price if she is a resident of Bamberg.

      -=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e fills a form and enters the requested information.
      =C2=A0She indicates that she is a resident of Bamberg and so she gets the discounted price.

      = -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e makes the payment using 3D secure.

      -<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e gets back a QR code on her phone that will be scanned when entering the concert hall.

      -<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e goes to the concert at Bamberg Symphony.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 At t= he entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert,
      =C2=A0her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only
      =C2=A0for the residents of Bamberg.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If t= he person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,
      =C2=A0she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
      ("On the Internet, nobody knows you're a dog". Peter Steiner's carto= on, as published in The New Yorker = on July 5, 1993).

      This is simple, efficient and easy to implement right now.

      This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket .
      If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask
      the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
      that the individual is indeed over 60 but in addition the name on the       identity card or the passport will be checked against the name on the railway
      ticket and that picture matches with the face of the person in front of the train controller.

      Anyway, IMHO, I don't bel= ieve that this use case should be solved using GNAP.

      Denis

      PS. This use= case has been posted here:
      https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-p= urchasing-a-concert-ticket-without-disclosing-her-identity

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



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


      --

      Hindle Consulting Limited is a company registered in England and Wa= les. =C2=A0Company number: 8888564.
      Registe= red office: Claremont House, 1 Market Square, Bicester, Oxfordshire OX26 6A= A, UK.
      --00000000000069e9f505ad6370a3-- From nobody Mon Aug 24 01:14:23 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 DA6493A0B6A for ; Mon, 24 Aug 2020 01:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.763 X-Spam-Level: * X-Spam-Status: No, score=1.763 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.361] autolearn=no autolearn_force=no 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 R_vjC_BCZjbs for ; Mon, 24 Aug 2020 01:14:20 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1833A0917 for ; Mon, 24 Aug 2020 01:14:19 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d12 with ME id KLEG230062bcEcA03LEGr9; Mon, 24 Aug 2020 10:14:17 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 24 Aug 2020 10:14:17 +0200 X-ME-IP: 90.79.51.120 From: Denis To: Justin Richer Cc: "txauth@ietf.org" Message-ID: <1cb7c404-7eb2-961b-d2b6-4f907a644597@free.fr> Date: Mon, 24 Aug 2020 10:14:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4F2351AC27AED4EBD0000D34" Content-Language: en-GB Archived-At: Subject: [GNAP] Two comments on draft-richer-transactional-authz-06 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, 24 Aug 2020 08:14:22 -0000 This is a multi-part message in MIME format. --------------4F2351AC27AED4EBD0000D34 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, I will post three emails today which are related. In order to ease discussion, this is done using three threads. First extract: 1.Protocol This protocol allows a piece of software to request delegated authorization to an API, protected by an authorization server /usually/ on behalf of a resource owner. In general, an access token is able to contain data that allows to support either ABAC (Attribute-based Access Control) or resource authorizations which allow to perform one or more operations on a data object protected by a RS (i.e. capabilities). The data associated with a user or with a client hosted by an Authorization Server may have two origins: * they may be /attributes/ granted by the AS itself which has verified somehow that these attributes indeed belong to a user or to a client, or * they may be resource authorizations (i.e. capabilities) granted by a Resource Controller (RC) with which the AS has a close relationship. These resource authorizations allow to perform one or more operations on one or more data objects protected by a RS. Proposed rewording: This protocol allows a client application to use an API hosted by a resource server (RS) by presenting to a resource server (RS) access tokens issued by an Authorization Server (AS). These access tokens may contain attributes related to a user or to a client application and/or resource authorizations (i.e. allowed operations on a data resource) granted to a user or to a client application by the resource controller (RC) of a RS with which the AS has a bi-lateral trust relationship. In addition, the protocol allows a user or a client to retrieve the attributes related to a user or to a client and/or resource authorizations granted by the Resource Controller (RC) of a RS to a user or to a client. Second extract: 2.Transaction request           To start a transaction, the RC makes a transaction request to the transaction endpoint of the AS. This is not necessarily the start of the story. There are two cases to consider, one of them is "AS centric" while the other one is "RS centric". When both the AS and the RS belong to the same domain, a bi-lateral trust relationship exists between the AS and the RS. However, when a RS is anywhere on the Internet, in general there is no bi-lateral relationship but only a unilateral trust relationship: a RS may simply trust an AS for the attributes it issues but the AS is unaware of the RSs that trust it. These two use cases should be supported. Proposed rewording: A transaction may be initiated by making a transaction request either to the transaction endpoint of the RS or to a transaction endpoint of the AS. The first case applies in general when the client does not know in advance which AS is or which ASs are trusted by a RS. The second case applies when the client knows in advance which AS is trusted by a RS and when a bi-lateral trust relationship exists between the AS and the RS, e.g. because they are in the same domain. 1) When a transaction is initiated by making a transaction request to the transaction endpoint of the RS, the client or the User MAY first need to authenticate         to the RS before being able to perform any kind of operation. The client or the User should be able to identify which authentication methods are supported.        This step is called "Authentication mechanism discovery". The client or the User should then be able to query the RS about the operations that are supported        by the RS. This step is called "API discovery".    2) When a transaction is initiated by making a transaction request to the transaction endpoint of the AS, the client or the User MUST first authenticate to the AS.        Hence, the client or the User should be able to identify which authentication methods are supported. This step is called "Authentication mechanism discovery". Denis PS. More details follow on the "Authentication mechanism discovery" and the " API discovery" using two separate threads. --------------4F2351AC27AED4EBD0000D34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Hi Justin,

      I will post three emails today which are related. In order to ease discussion, this is done using three threads.

      First extract:

            1.  Protocol

                 This protocol allows a piece of software to request delegated authorization to an API, protected by an authorization server usually on behalf of a resource owner.

      In general, an access token is able to contain data that allows to support either ABAC (Attribute-based Access Control) or resource authorizations which allow to perform
      one or more operations on a data object protected by a RS       (i.e. capabilities). The data associated with a user or with a client hosted by an Authorization Server
      may have two origins:

      • they may be attributes granted by the AS itself which has verified somehow that these attributes indeed belong to a user or to a client, or
      • they may be resource authorizations (i.e. capabilities) granted by a Resource Controller (RC) with which the AS has a close relationship.
        These resource authorizations allow to perform one or more operations on one or more data objects protected by a RS.

      Proposed rewording:

       This protocol allows a client application to use an API hosted by a resource server (RS) by presenting to a resource server (RS) access tokens issued
      by an Authorization Server (AS). These access tokens may contain attributes related to a user or to a client application and/or resource authorizations
      (i.e. allowed operations on a data resource) granted to a user or to a client application by the resource controller (RC) of a RS with which the AS has
      a bi-lateral trust relationship. In addition, the protocol allows a user or a client to retrieve the attributes related to a user or to a client and/or resource
      authorizations granted by the Resource Controller (RC) of a RS to a user or to a client.

      Second extract:

            2.  Transaction request

                To start a transaction, the RC makes a transaction request to the transaction endpoint of the AS.

      This is not necessarily the start of the story. There are two cases to consider, one of them is "AS centric" while the other one is "RS centric".

      When both the AS and the RS belong to the same domain, a bi-lateral trust relationship exists between the AS and the RS.
      However, when a RS is anywhere on the Internet, in general there is no bi-lateral relationship but only a unilateral trust relationship:
      a RS may simply trust an AS for the attributes it issues but the AS is unaware of the RSs that trust it. These two use cases should be supported.

      Proposed rewording:

       A transaction may be initiated by making a transaction request either to the transaction endpoint of the RS or to a transaction endpoint of the AS.
      The first case applies in general when the client does not know in advance which AS is or which ASs are trusted by a RS. The second case applies
      when the client knows in advance which AS is trusted by a RS and when a bi-lateral trust relationship exists between the AS and the RS, e.g. because
      they are in the same domain.

          1) When a transaction is initiated by making a transaction request to the transaction endpoint of the RS, the client or the User MAY first need to authenticate
              to the RS before being able to perform any kind of operation. The client or the User should be able to identify which authentication methods are supported.
             This step is called "Authentication mechanism discovery". The client or the User should then be able to query the RS about the operations that are supported
             by the RS. This step is called "API discovery".

         2) When a transaction is initiated by making a transaction request to the transaction endpoint of the AS, the client or the User MUST first authenticate to the AS.
             Hence, the client or the User should be able to identify which authentication methods are supported. This step is called "Authentication mechanism discovery".

      Denis

      PS. More details follow on the "Authentication mechanism discovery" and the " API discovery" using two separate threads.

      --------------4F2351AC27AED4EBD0000D34-- From nobody Mon Aug 24 01:16:50 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 A79663A0B6E for ; Mon, 24 Aug 2020 01:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.764 X-Spam-Level: * X-Spam-Status: No, score=1.764 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.361, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 sSNEOi5WHkfm for ; Mon, 24 Aug 2020 01:16:47 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820813A0B6A for ; Mon, 24 Aug 2020 01:16:46 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d12 with ME id KLGk230062bcEcA03LGk8A; Mon, 24 Aug 2020 10:16:44 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 24 Aug 2020 10:16:44 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" From: Denis Message-ID: Date: Mon, 24 Aug 2020 10:16:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------87FD90956CFCC7F2EB3E4236" Content-Language: en-GB Archived-At: Subject: [GNAP] Authentication mechanisms discovery 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, 24 Aug 2020 08:16:49 -0000 This is a multi-part message in MIME format. --------------87FD90956CFCC7F2EB3E4236 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick*, * The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13. *1 ) Authentication mechanisms discovery at the GS* Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful. The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7). RFC 7231 mentions: A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing       the representation media type.Although this specification does not define any use for such a payload, future extensions to HTTP       might use the OPTIONS body to make more detailed queries about the target resource. RFC 7231 also mentions: A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features       implemented by the server and applicable to the target resource, including potential extensions not defined by this specification. However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing the representation media type, since the client is knowing whether it is acting or not on behalf of a User.* * *2) Authentication mechanisms discovery at the RS* This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication methods that are /currently/ supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well. Denis --------------87FD90956CFCC7F2EB3E4236 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

            A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
            A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
            the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP
            might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

            A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
            implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

      --------------87FD90956CFCC7F2EB3E4236-- From nobody Mon Aug 24 01:19:44 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 BAB1C3A0B72 for ; Mon, 24 Aug 2020 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.764 X-Spam-Level: * X-Spam-Status: No, score=1.764 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.361, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 iXUDAJMbZrPz for ; Mon, 24 Aug 2020 01:19:41 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D5B3A0B71 for ; Mon, 24 Aug 2020 01:19:40 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d12 with ME id KLKe2300T2bcEcA03LKeQS; Mon, 24 Aug 2020 10:19:39 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 24 Aug 2020 10:19:39 +0200 X-ME-IP: 90.79.51.120 To: "txauth@ietf.org" From: Denis Message-ID: <0cf1f1e6-654b-26e4-2961-27ee4e957f33@free.fr> Date: Mon, 24 Aug 2020 10:19:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0006CBCD9876890801C297A8" Content-Language: en-GB Archived-At: Subject: [GNAP] API discovery 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, 24 Aug 2020 08:19:43 -0000 This is a multi-part message in MIME format. --------------0006CBCD9876890801C297A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To the list, **A discovery mechanism should be usable to discover which actions are possible on the RS. This can be seen as a means to implement some aspects of the level 3 of the Richardson Maturity Model (RMM): HATEOAS (Hypermedia as the Engine of Application State) but combined with access control, i.e. knowing at the same time which actions that can be done and the access control characteristics associated with these actions which is an aspect that is not addressed in HATEOAS. Such an API discovery mechanism could be used before or after authentication has been achieved on the RS. If the API discovery mechanism is used before authentication has been achieved, the RS might indicate that no operation is available at this time which would means that the available operations will only be disclosed once authentication has been achieved. See the simple example from : https://en.wikipedia.org/wiki/HATEOAS which is using a GET request. It is important to notice in that example that the allowed actions that are possible varies dynamically as the state of the resource varies. Using an appropriate HTTP OPTIONS request, the client (or its User) should be able to know: * which actions that can be done (i.e. which methods are available on which data objects), and * the access control characteristics associated with each of these actions (i.e. which ASs are being trusted by the RS and what should be incorporated into access token(s) in terms of attributes types (and optionally attribute values) or in terms of capabilities (i.e. permissions granted by a Resource Controller). In the case where the request is made on behalf of a User, this information should be usable by the User Agent of the client in order to capture the User Consent. The selection made by the User should then be sent back to the client, so that the client would be able to request the appropriate access tokens from the appropriate ASs. Then after, at every step further in the processing of a transaction, the client would be able to issue another HTTP OPTIONS request. A client supporting JavaScript would be able to take a full advantage of such an approach. Using an appropriate format indication in the HTTP OPTIONS request, it would even be possible to get a response directly processable under a client supporting JavaScript. A less ambitious approach would be to tell to the client the access control rules that apply once an operation has been selected (instead of before the operation has been selected). Denis --------------0006CBCD9876890801C297A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

      To the list,

      A discovery mechanism should be usable to discover which actions are possible on the RS.

      This can be seen as a means to implement some aspects of the level 3 of the Richardson Maturity Model (RMM):
      HATEOAS (Hypermedia as the Engine of Application State) but combined with access control, i.e. knowing at the same time
      which actions that can be done and the access control characteristics associated with these actions which is an aspect
      that is not addressed in HATEOAS.

      Such an API discovery mechanism could be used before       or after authentication has been achieved on the RS.

      If the API discovery mechanism is used before authentication has been achieved, the RS might indicate that no operation is available
      at this time which would means that the available operations will only be disclosed once authentication has been achieved.

      See the simple example from : https://en.wikipedia.org/wiki/HATEOAS which is using a GET request.
      It is important to notice in that example that the allowed actions that are possible varies dynamically as the state of the resource varies.

      Using an appropriate HTTP OPTIONS request, the client (or its User) should be able to know:

      • which actions that can be done (i.e. which methods are available on which data objects), and
      • the access control characteristics associated with each of these actions (i.e. which ASs are being trusted by the RS
        and what should be incorporated into access token(s) in terms of attributes types (and optionally attribute values)
        or in terms of capabilities (i.e. permissions granted by a Resource Controller).

      In the case where the request is made on behalf of a User, this information should be usable by the User Agent of the client in order to capture the User Consent.
      The selection made by the User should then be sent back to the client, so that the client would be able to request the appropriate access tokens from the appropriate ASs.

      Then after, at every step further in the processing of a transaction, the client would be able to issue another HTTP OPTIONS request.

      A client supporting JavaScript would be able to take a full advantage of such an approach. Using an appropriate format indication in the HTTP OPTIONS request,
      it would even be possible to get a response directly processable under a client supporting JavaScript.

      A less ambitious approach would be to tell to the client the access control rules that apply once an operation has been selected
      (instead of before the operation has been selected).

      Denis

      --------------0006CBCD9876890801C297A8-- From nobody Mon Aug 24 09:06:04 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 EE7AB3A0F8D for ; Mon, 24 Aug 2020 09:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 71cVmS9ubtKb for ; Mon, 24 Aug 2020 09:06:01 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 C05473A0D72 for ; Mon, 24 Aug 2020 09:06:00 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id v4so10305927ljd.0 for ; Mon, 24 Aug 2020 09:06:00 -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=hP88vLxShlBtMsueNRc5yZTXQxOddqOC94ShTXolEno=; b=QFa4k4aquzE2DHYNjQxBBmZB4yyQnyWqI4uPL2EFSP8fHhz9NSNIGnxEFC95m0ubt3 44DBXm6Y4zeX1vnn+rJchXEu0Qvhhc9o8TkldBqCP0kg3kBV2GM/Mj3JGwuglVeWy6EG treDN2RBe8/sNct6Q9ZRqZGnTdoyfr3FrVDbkpDcdqVTcCKnSCcsm05M1czOy4/6NxQT qJN2GrX/N8WAYNJLRn83seh0/+LQ/5zsDycNAEa5N+JmfMFO5ZdsgHpSzUy6ejEDMTLe nkIMvOJHPgtuyBJNNdzuOmoc0AdYCvh7pBSt/G2r1j/uWRI99XyimAtk4bCNGHgdNeTq CZyw== 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=hP88vLxShlBtMsueNRc5yZTXQxOddqOC94ShTXolEno=; b=KdG0+MWkX75+54Fx+mLASXH3yxj6hD78CZAa3SfzcvnxXZe4bnfv3pF4/qM7iVK+IV jp13mG5TVms/hcKCOBZ6xJKj+C5n9K/J67V6Cr1K83o5SHnYAU++s/L4jhAHBgy9pWc4 yJ6YH/aBHZGs1OS/OtCBMizbl6GowFzZu1acrNPRPplqrEaDISlJkRqJpPEqcvpyRhVK QImwr+ES8DRLW/OD4HXeYKyeAbJi1JRPFJVZVVwqA/OzXWMUukgBxGs2I0R7MPrrzBno nLrn8apIP+L9gM78I9B+FJ5Yt+8Ui/kKhyitQ3EZPsxZpKH8ORDQYZ+uZjrgw/0177l7 TWvg== X-Gm-Message-State: AOAM531XICaDGMICnz1nroU6WhJs6rBsnyuaPUT7d5F3u82SKmnTdEZ0 +RMdxa169j204/QFwPC9sOumeAAYZLmfr6ZMaoM= X-Google-Smtp-Source: ABdhPJwfSKpHG8ngVbyce0imk+/JBXwMwxk3h1VmSjocdXXVolqII1N1RLfgFQaT70FmzOHrgXW8gxMm06rjQOhCLe4= X-Received: by 2002:a2e:a16f:: with SMTP id u15mr3138040ljl.5.1598285158508; Mon, 24 Aug 2020 09:05:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 24 Aug 2020 09:05:22 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001f6d2905ada1c313" Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 24 Aug 2020 16:06:03 -0000 --0000000000001f6d2905ada1c313 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis While it is an interesting idea to use the OPTIONS method at the RS, the standard way to indicate authentication mechanisms is with a 401 HTTP response per https://tools.ietf.org/html/rfc7235#section-3.1 And then information about how to authenticate may be in the HTTP Authorization header. This allows an RS to respond to any request including an OPTIONS method call. /Dick =E1=90=A7 On Mon, Aug 24, 2020 at 1:16 AM Denis wrote: > Hi Dick > *, * > > The following comments have been elaborated after an analysis of your > draft: draft-hardt-xauth-protocol-13. > > *1 ) Authentication mechanisms discovery at the GS* > > Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to > support an HTTP OPTIONS request which would be the first request > when talking to a GS. The goal is to be able to query the authentication > mechanisms supported by the GS. This would indeed be very useful. > > The HTTP OPTIONS request has been first defined in RFC 2616 and refined i= n > RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7). > > RFC 7231 mentions: > > A standard format for such a representation is not defined by this > specification, but might be defined by future extensions to HTTP. > A client that generates an OPTIONS request containing a payload bod= y > MUST send a valid Content-Type header field describing > the representation media type. Although this specification does > not define any use for such a payload, future extensions to HTTP > might use the OPTIONS body to make more detailed queries about the > target resource. > > RFC 7231 also mentions: > > A server generating a successful response to OPTIONS SHOULD send an > header fields that might indicate optional features > implemented by the server and applicable to the target resource, > including potential extensions not defined by this specification. > > However, two types of authentication are possible: user authentication an= d > client authentication. If both are supported by the GS, it would be > possible > to address this concern either by returning two lists of authentication > methods or even better by using two different Content-Type header fields > describing > the representation media type, since the client is knowing whether it is > acting or not on behalf of a User. > > *2) Authentication mechanisms discovery at the RS* > > This HTTP OPTIONS request should also be supported by a RS. When a client > first contacts a RS, it does not necessarily know the authentication > methods that are *currently* supported by the RS. This means that the > same request as the one used for the GS should be available for a RS as > well. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001f6d2905ada1c313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hi Denis

      While it is an interesting ide= a to use the OPTIONS method at the RS, the standard way to indicate authent= ication mechanisms is with a 401 HTTP response per

      And t= hen information about how to authenticate may be in the HTTP Authorization = header.

      This allows an RS to respond to any reques= t including an OPTIONS method call.

      /Dick


      3D""=E1=90=A7

      On Mon, Aug 24, 2= 020 at 1:16 AM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-prot= ocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/ht= ml/rfc7231#section-4.3.7).

      RFC 7231 mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
      =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the representation media type.=C2=A0 Although this specification does not define any use for such a payload, future extensions to HTTP
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --0000000000001f6d2905ada1c313-- From nobody Mon Aug 24 09:10:33 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 28E9E3A0F84 for ; Mon, 24 Aug 2020 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 zMidkgIW8JGz for ; Mon, 24 Aug 2020 09:10:31 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 8C6823A10AA for ; Mon, 24 Aug 2020 09:10:17 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id m22so10305346ljj.5 for ; Mon, 24 Aug 2020 09:10:17 -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=g94+wMev1dRZ4RwFn5Re79ALIF36w3dzuimbmvmeMf0=; b=rr8LI08iJzLv8Md3QOObqcgNVL+/KqHcCZFmITpJsXQvyw5PbQz/3PWFIXYbU7YkAr NBfONAUfN0U+DTm8dxmdV7LthafOvIw5yhz17rz7tZjQjyQhaS86CKto43Po4c8mw/dj e7Dec+QGl1IQt+CeZ3Dv7OTVG2CwP+VwmdKX5sZU/SZN3sSHnlYWOBF+Vk8y8S+c9lvp jOHAfhwrdphJJRsh0Rnq57V7rIgSeoxyaFaCVkkSLn0Qk417a2L7+/n4czcmRsCshfe1 mso3WDcVPXlAw6gAY+XZol828BB19VkSQete9/XRSwpR+ksE5jxI0fEFm7GyBcNuV2Gu h+hw== 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=g94+wMev1dRZ4RwFn5Re79ALIF36w3dzuimbmvmeMf0=; b=D6n38//LrcjfND97ICbEMzMiAZWZIY3YYcqktUwU1Cx8afRAJ1iCzzLd7ZJEp5u6ot FzW5nwLU5iNfEurTTD32UKAu+UmvihMU/KJ7DX2pFNckHdQoTmmvqEi3v39mU4rc3vqT RC9qZLmFjaf4A7hjw16N31n9+6U3qTo5poWO2BqeYheEQKYEHdyM8PEpMvFY5+MdDak1 GMOxONxVms9rjJuMFGYFAQkN9CENowpzcxRCe+GIsGAlh1OvNfXZDdq7J8TIvKWTL/ep wFOCi59oZu9Xm+e+oqx/J6I+U7//FSHY7s4M3T/tVZc5qRxaWiZZOUkxQipZmmTbFl8m htUQ== X-Gm-Message-State: AOAM532sICDGfc7vd/IlBJ+Dv255wiw6sonYuMPculNgk8JMiqJHysmw iseC+7AedCCAMWw+kS18vZM0DSmlBqRxtfIr4xw= X-Google-Smtp-Source: ABdhPJyBLXGgOu02OcKmJDK36AHRhR64+/KbwcCQqbZNNukc1Y/ImR+A6QnOCmJuI+I0VrirWJCaa5GAeLHtJIRPka4= X-Received: by 2002:a2e:2283:: with SMTP id i125mr2907759lji.142.1598285415599; Mon, 24 Aug 2020 09:10:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 24 Aug 2020 09:09:39 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000725f1f05ada1d235" Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 24 Aug 2020 16:10:33 -0000 --000000000000725f1f05ada1d235 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A comment about an OPTIONS call being the first call in the protocol. While that is possible, I expect most use of the discovery will happen by tooling rather than client software. IE, when developing against an GS, the developers tool chain will check what the GS supports. On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt wrote: > Hi Denis > > While it is an interesting idea to use the OPTIONS method at the RS, the > standard way to indicate authentication mechanisms is with a 401 HTTP > response per > https://tools.ietf.org/html/rfc7235#section-3.1 > > And then information about how to authenticate may be in the HTTP > Authorization header. > > This allows an RS to respond to any request including an OPTIONS method > call. > > /Dick > > > =E1=90=A7 > > On Mon, Aug 24, 2020 at 1:16 AM Denis wrote: > >> Hi Dick >> *, * >> >> The following comments have been elaborated after an analysis of your >> draft: draft-hardt-xauth-protocol-13. >> >> *1 ) Authentication mechanisms discovery at the GS* >> >> Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to >> support an HTTP OPTIONS request which would be the first request >> when talking to a GS. The goal is to be able to query the authentication >> mechanisms supported by the GS. This would indeed be very useful. >> >> The HTTP OPTIONS request has been first defined in RFC 2616 and refined >> in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7). >> >> RFC 7231 mentions: >> >> A standard format for such a representation is not defined by this >> specification, but might be defined by future extensions to HTTP. >> A client that generates an OPTIONS request containing a payload >> body MUST send a valid Content-Type header field describing >> the representation media type. Although this specification does >> not define any use for such a payload, future extensions to HTTP >> might use the OPTIONS body to make more detailed queries about the >> target resource. >> >> RFC 7231 also mentions: >> >> A server generating a successful response to OPTIONS SHOULD send a= n >> header fields that might indicate optional features >> implemented by the server and applicable to the target resource, >> including potential extensions not defined by this specification. >> >> However, two types of authentication are possible: user authentication >> and client authentication. If both are supported by the GS, it would be >> possible >> to address this concern either by returning two lists of authentication >> methods or even better by using two different Content-Type header fields >> describing >> the representation media type, since the client is knowing whether it is >> acting or not on behalf of a User. >> >> *2) Authentication mechanisms discovery at the RS* >> >> This HTTP OPTIONS request should also be supported by a RS. When a clien= t >> first contacts a RS, it does not necessarily know the authentication >> methods that are *currently* supported by the RS. This means that the >> same request as the one used for the GS should be available for a RS as >> well. >> >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000725f1f05ada1d235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      A comment about an OPTIONS call being the first call in th= e protocol.

      While that is possible, I expect most use of= the discovery will happen by tooling rather than client software. IE, when= developing against an GS, the developers tool chain will check what the GS= supports.

      On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Denis
      While it is an interesting idea to use the OPTIONS method= at the RS, the standard way to indicate authentication mechanisms is with = a 401 HTTP response per

      And then information about how t= o authenticate may be in the HTTP Authorization header.

      This allows an RS to respond to any request including an OPTIONS meth= od call.

      /Dick


      =
      3D""==E1=90=A7

      <= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 24, 2020 at 1:16 AM Denis = <denis.ietf@free= .fr> wrote:
      =20 =20 =20

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-prot= ocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/ht= ml/rfc7231#section-4.3.7).

      RFC 7231 mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
      =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the representation media type.=C2=A0 Although this specification does not define any use for such a payload, future extensions to HTTP
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --000000000000725f1f05ada1d235-- From nobody Mon Aug 24 13:12:15 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 3CB933A0BDE for ; Mon, 24 Aug 2020 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 M8wYnTd8FQK2 for ; Mon, 24 Aug 2020 13:12:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34653A0BDC for ; Mon, 24 Aug 2020 13:12:11 -0700 (PDT) Received: from [192.168.1.11] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07OKC7Bc009764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Aug 2020 16:12:08 -0400 From: Justin Richer Message-Id: <247CA426-CB07-482F-ADFB-B8CE8AC9D8E2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_7990B37A-27E6-494C-8E89-34A025CAD4F1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 24 Aug 2020 16:12:07 -0400 In-Reply-To: Cc: Dick Hardt , "txauth@ietf.org" To: Denis References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 24 Aug 2020 20:12:14 -0000 --Apple-Mail=_7990B37A-27E6-494C-8E89-34A025CAD4F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis, thanks for writing this up. I don=E2=80=99t think we want to get = into the business of defining what an API should do for service and = capability discovery, especially since there are a wide variety of API = patterns and styles out there, each with their own discovery principles. = I agree with Dick that the right way to approach this is likely to use = the =E2=80=9CWWW-Authenticate=E2=80=9D header response, which is what = I=E2=80=99ve proposed as a straw man in section 10.4 of XYZ: = https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10= .4 = For use cases like yours where the client starts at the RS, this makes a = lot of sense and the RS can point the client toward the AS it should be = using, and even tell it what kind of thing it needs to ask for next. = There=E2=80=99s a lot of work we can do there to make that robust and = useful. But, just like AS discovery, I think that=E2=80=99s an optimization for = cases where that information isn=E2=80=99t known by some other means. = It=E2=80=99s my stance that, wherever possible, discovery should be an = optional add-on to let software optimize the experience, not something = required for the protocol to work. =E2=80=9CDiscovery=E2=80=9D and = =E2=80=9Cregistration=E2=80=9D assume a mostly-static world, where = sysadmins are making security decisions ahead of time and assigning = identifiers to those decisions. I think that if we take a step back and = look at the fundamentals of what we=E2=80=99re trying to solve here, we = don=E2=80=99t actually need discovery or registration a lot of the time, = and certainly not as add-ons like they are in OAuth 2. When I wrote XYZ, one of the goals was for it to be =E2=80=9Cdynamic = first=E2=80=9D, so that the client and server wouldn=E2=80=99t :need: to = know anything about each other ahead of time in order for the core = protocol to work. Now of course, in many cases, the AS is only going to = trust calls from keys that it=E2=80=99s seen as part of a static = registration record, and a client is going to be configured or = programmed to only take actions that are available at the AS it=E2=80=99s = been written to talk to. But it=E2=80=99s important to me that these = cases are optimizations on the overall protocol, which (unlike OAuth) = doesn=E2=80=99t assume a discovery or registration step happened out of = band first.=20 In today=E2=80=99s world, we=E2=80=99ve got so many signals that = software can send each other at runtime that can be processed and likely = trusted much more than a static discovery/registration ever could. The = client can send over device posture, organizational affiliation = attestations, verifiable credentials of the current user (without the AS = ever seeing the user), derived credentials that are tied to some = external trusted registry (think of a CA style model but for more than = certificates), or any number of other signals that people are using and = building. None of these lend themselves to OAuth=E2=80=99s =E2=80=9Cclient= _id is required everywhere=E2=80=9D model, which was built around a = notion of two web sites talking to each other. That=E2=80=99s why I = think we should not only be getting away from the discovery/registration = mindset and towards a dynamic-first negotiated protocol which can, in = turn, be optimized in a secure and clean fashion. =E2=80=94 Justin > On Aug 24, 2020, at 4:16 AM, Denis wrote: >=20 >=20 > Hi Dick,=20 >=20 > The following comments have been elaborated after an analysis of your = draft: draft-hardt-xauth-protocol-13. >=20 > 1 ) Authentication mechanisms discovery at the GS >=20 > Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to = support an HTTP OPTIONS request which would be the first request=20 > when talking to a GS. The goal is to be able to query the = authentication mechanisms supported by the GS. This would indeed be very = useful. >=20 > The HTTP OPTIONS request has been first defined in RFC 2616 and = refined in RFC 7231 (see = https://tools.ietf.org/html/rfc7231#section-4.3.7 = ). >=20 > RFC 7231 mentions: >=20 > A standard format for such a representation is not defined by = this specification, but might be defined by future extensions to HTTP. > A client that generates an OPTIONS request containing a payload = body MUST send a valid Content-Type header field describing=20 > the representation media type. Although this specification does = not define any use for such a payload, future extensions to HTTP=20 > might use the OPTIONS body to make more detailed queries about = the target resource. >=20 > RFC 7231 also mentions: >=20 > A server generating a successful response to OPTIONS SHOULD send = an header fields that might indicate optional features=20 > implemented by the server and applicable to the target resource, = including potential extensions not defined by this specification. >=20 > However, two types of authentication are possible: user authentication = and client authentication. If both are supported by the GS, it would be = possible=20 > to address this concern either by returning two lists of = authentication methods or even better by using two different = Content-Type header fields describing=20 > the representation media type, since the client is knowing whether it = is acting or not on behalf of a User. >=20 > 2) Authentication mechanisms discovery at the RS >=20 > This HTTP OPTIONS request should also be supported by a RS. When a = client first contacts a RS, it does not necessarily know the = authentication=20 > methods that are currently supported by the RS. This means that the = same request as the one used for the GS should be available for a RS as = well. >=20 > Denis >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_7990B37A-27E6-494C-8E89-34A025CAD4F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis, thanks for writing this up. I don=E2=80=99t think we = want to get into the business of defining what an API should do for = service and capability discovery, especially since there are a wide = variety of API patterns and styles out there, each with their own = discovery principles. I agree with Dick that the right way to approach = this is likely to use the =E2=80=9CWWW-Authenticate=E2=80=9D header = response, which is what I=E2=80=99ve proposed as a straw man in section = 10.4 of XYZ:

      https://tools.ietf.org/html/draft-richer-transactional-authz-09= #section-10.4

      For use cases like yours where the client starts at the RS, = this makes a lot of sense and the RS can point the client toward the AS = it should be using, and even tell it what kind of thing it needs to ask = for next. There=E2=80=99s a lot of work we can do there to make that = robust and useful.

      But, just like AS discovery, I think that=E2=80=99s an = optimization for cases where that information isn=E2=80=99t known by = some other means. It=E2=80=99s my stance that, wherever possible, = discovery should be an optional add-on to let software optimize the = experience, not something required for the protocol to work. = =E2=80=9CDiscovery=E2=80=9D and =E2=80=9Cregistration=E2=80=9D assume a = mostly-static world, where sysadmins are making security decisions ahead = of time and assigning identifiers to those decisions. I think that if we = take a step back and look at the fundamentals of what we=E2=80=99re = trying to solve here, we don=E2=80=99t actually need discovery or = registration a lot of the time, and certainly not as add-ons like they = are in OAuth 2.

      When I wrote XYZ, one of the goals was = for it to be =E2=80=9Cdynamic first=E2=80=9D, so that the client and = server wouldn=E2=80=99t :need: to know anything about each other ahead = of time in order for the core protocol to work. Now of course, in many = cases, the AS is only going to trust calls from keys that it=E2=80=99s = seen as part of a static registration record, and a client is going to = be configured or programmed to only take actions that are available at = the AS it=E2=80=99s been written to talk to. But it=E2=80=99s important = to me that these cases are optimizations on the overall protocol, which = (unlike OAuth) doesn=E2=80=99t assume a discovery or registration step = happened out of band first. 

      In today=E2=80=99s world, we=E2=80=99ve = got so many signals that software can send each other at runtime that = can be processed and likely trusted much more than a static = discovery/registration ever could. The client can send over device = posture, organizational affiliation attestations, verifiable credentials = of the current user (without the AS ever seeing the user), derived = credentials that are tied to some external trusted registry (think of a = CA style model but for more than certificates), or any number of other = signals that people are using and building. None of these lend = themselves to OAuth=E2=80=99s =E2=80=9Cclient_id is required = everywhere=E2=80=9D model, which was built around a notion of two web = sites talking to each other. That=E2=80=99s why I think we should not = only be getting away from the discovery/registration mindset and towards = a dynamic-first negotiated protocol which can, in turn, be optimized in = a secure and clean fashion.

       =E2=80=94 Justin

      On Aug = 24, 2020, at 4:16 AM, Denis <denis.ietf@free.fr> wrote:

      =20

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the = GS

      Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.i= etf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

            A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
            A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
            the representation media type.  = Although this specification does not define any use for such a payload, future extensions to HTTP
            might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

            A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
            implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS
      =
      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication =
      methods that are currently supported by the RS. This means that = the same request as the one used for the GS should be available for a RS as = well.

      Denis
      =

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

      = --Apple-Mail=_7990B37A-27E6-494C-8E89-34A025CAD4F1-- From nobody Mon Aug 24 15:36:00 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 A41583A0E34 for ; Mon, 24 Aug 2020 15:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 3OnpjHqUQRNw for ; Mon, 24 Aug 2020 15:35:57 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 516AD3A0E30 for ; Mon, 24 Aug 2020 15:35:57 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id o8so6064329otp.9 for ; Mon, 24 Aug 2020 15:35:57 -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=+cnLaJKf5oFMH7kNs134DnYz+rCQz7YhYxQKg6HXBV8=; b=LkS2r0+0KQy50ZCU7agkgh/fY8+p1+KRgEo1bVopNdPIvIFdt9iRGPWbAJHQg/M/Zm RjOMQvPV8Kv37Tv5aHs7pKjENU6GHZtohBmWegcSHORGab3nb6axNViTL2QRU0Q6csTB Vr0qU9MtCTI+Zyocu7JfoegYicqo0OlO80Q9j20+8Ff9nWA1ddc8KQUZy+1QP6ikVlGp o4AmCNi3QAuM/XlXCCq2eNSFsx1x29G9Dr06zN7XYRF96D2MCTzKl0Kl5CvyaSRq2hgP RzmQ9hwX74kkjTg4O7G8VrWkGYqY04TGNI/jgIWlL9mtkIGquyp0r5gEgscMgzvi7yxU cpzA== 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=+cnLaJKf5oFMH7kNs134DnYz+rCQz7YhYxQKg6HXBV8=; b=unKcSn6aHHsthWquOn3kQkhxv0rPYIPGb2lS68oI4Esx4PM7gtdb6LX2Uo/8+03g7/ 5pTpLSEJ964PdOY34GxRiA+8FuNF6Q3fTX1r8Wl9J0rzA9pnk1UTbHy3cI4/YY7R3bCV P8+D1x3vMTr220D/TMoHG3Skrhc7114m/tcTKWG3ouPolXutNhnRS2upeIbfp/by+KMG VWc1hzbZoqd6cZNDXye/wxUIrDaVkC4N9PLrHZiSDxCOYm9PA6fnNX4VWUlCUnMzv94+ 8KApTsBF7+1njR8AqZ2h3doXmdNXPVWqWm60jNtL0xtST82bwQNHOccuBv3pX8t+E3vJ LJ2g== X-Gm-Message-State: AOAM532OtSmKgpEIj1obRiXAmIxM0rnxr3j7YyFxSo2ij3oXrAnDOF4I QXIwJzc5dF4ZROnmMJqImG83oukVvmMjr+Ww4Rc= X-Google-Smtp-Source: ABdhPJwexNSJUllcbNsu4mD75WElfgrqQSqtjgUDeb9gNyj1Oibae/Cr8ssvzyFMevXQsMwE/jhabQxB55JSSCJBJBo= X-Received: by 2002:a9d:683:: with SMTP id 3mr4777881otx.87.1598308556402; Mon, 24 Aug 2020 15:35:56 -0700 (PDT) MIME-Version: 1.0 References: <247CA426-CB07-482F-ADFB-B8CE8AC9D8E2@mit.edu> In-Reply-To: <247CA426-CB07-482F-ADFB-B8CE8AC9D8E2@mit.edu> From: Tom Jones Date: Mon, 24 Aug 2020 15:35:45 -0700 Message-ID: To: Justin Richer Cc: Denis , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000bef33905ada73533" Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 24 Aug 2020 22:36:00 -0000 --000000000000bef33905ada73533 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If anyone is interested in contributing to a Mobile Authentication Assurance Statement, let me know. We have one in process now in Kantara. It's our view that it would just be a signed jwt that could be included anywhere it was needed. Peace ..tom On Mon, Aug 24, 2020 at 1:12 PM Justin Richer wrote: > Denis, thanks for writing this up. I don=E2=80=99t think we want to get i= nto the > business of defining what an API should do for service and capability > discovery, especially since there are a wide variety of API patterns and > styles out there, each with their own discovery principles. I agree with > Dick that the right way to approach this is likely to use the > =E2=80=9CWWW-Authenticate=E2=80=9D header response, which is what I=E2=80= =99ve proposed as a straw > man in section 10.4 of XYZ: > > > https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-1= 0.4 > > For use cases like yours where the client starts at the RS, this makes a > lot of sense and the RS can point the client toward the AS it should be > using, and even tell it what kind of thing it needs to ask for next. > There=E2=80=99s a lot of work we can do there to make that robust and use= ful. > > But, just like AS discovery, I think that=E2=80=99s an optimization for c= ases > where that information isn=E2=80=99t known by some other means. It=E2=80= =99s my stance > that, wherever possible, discovery should be an optional add-on to let > software optimize the experience, not something required for the protocol > to work. =E2=80=9CDiscovery=E2=80=9D and =E2=80=9Cregistration=E2=80=9D a= ssume a mostly-static world, where > sysadmins are making security decisions ahead of time and assigning > identifiers to those decisions. I think that if we take a step back and > look at the fundamentals of what we=E2=80=99re trying to solve here, we d= on=E2=80=99t > actually need discovery or registration a lot of the time, and certainly > not as add-ons like they are in OAuth 2. > > When I wrote XYZ, one of the goals was for it to be =E2=80=9Cdynamic firs= t=E2=80=9D, so > that the client and server wouldn=E2=80=99t :need: to know anything about= each > other ahead of time in order for the core protocol to work. Now of course= , > in many cases, the AS is only going to trust calls from keys that it=E2= =80=99s seen > as part of a static registration record, and a client is going to be > configured or programmed to only take actions that are available at the A= S > it=E2=80=99s been written to talk to. But it=E2=80=99s important to me th= at these cases are > optimizations on the overall protocol, which (unlike OAuth) doesn=E2=80= =99t assume > a discovery or registration step happened out of band first. > > In today=E2=80=99s world, we=E2=80=99ve got so many signals that software= can send each > other at runtime that can be processed and likely trusted much more than = a > static discovery/registration ever could. The client can send over device > posture, organizational affiliation attestations, verifiable credentials = of > the current user (without the AS ever seeing the user), derived credentia= ls > that are tied to some external trusted registry (think of a CA style mode= l > but for more than certificates), or any number of other signals that peop= le > are using and building. None of these lend themselves to OAuth=E2=80=99s = =E2=80=9Cclient_id > is required everywhere=E2=80=9D model, which was built around a notion of= two web > sites talking to each other. That=E2=80=99s why I think we should not onl= y be > getting away from the discovery/registration mindset and towards a > dynamic-first negotiated protocol which can, in turn, be optimized in a > secure and clean fashion. > > =E2=80=94 Justin > > On Aug 24, 2020, at 4:16 AM, Denis wrote: > > > Hi Dick > *, * > > The following comments have been elaborated after an analysis of your > draft: draft-hardt-xauth-protocol-13. > > *1 ) Authentication mechanisms discovery at the GS* > > Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to > support an HTTP OPTIONS request which would be the first request > when talking to a GS. The goal is to be able to query the authentication > mechanisms supported by the GS. This would indeed be very useful. > > The HTTP OPTIONS request has been first defined in RFC 2616 and refined i= n > RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7). > > RFC 7231 mentions: > > A standard format for such a representation is not defined by this > specification, but might be defined by future extensions to HTTP. > A client that generates an OPTIONS request containing a payload bod= y > MUST send a valid Content-Type header field describing > the representation media type. Although this specification does > not define any use for such a payload, future extensions to HTTP > might use the OPTIONS body to make more detailed queries about the > target resource. > > RFC 7231 also mentions: > > A server generating a successful response to OPTIONS SHOULD send an > header fields that might indicate optional features > implemented by the server and applicable to the target resource, > including potential extensions not defined by this specification. > > However, two types of authentication are possible: user authentication an= d > client authentication. If both are supported by the GS, it would be > possible > to address this concern either by returning two lists of authentication > methods or even better by using two different Content-Type header fields > describing > the representation media type, since the client is knowing whether it is > acting or not on behalf of a User. > > *2) Authentication mechanisms discovery at the RS* > > This HTTP OPTIONS request should also be supported by a RS. When a client > first contacts a RS, it does not necessarily know the authentication > methods that are *currently* supported by the RS. This means that the > same request as the one used for the GS should be available for a RS as > well. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000bef33905ada73533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      If anyone is interested in contributing to a Mobile Authen= tication Assurance Statement, let me know.
      We have one in process now i= n Kantara. It's our view that it would just be a signed jwt that could = be included anywhere it was needed.
      Peace ..tom


      On Mon, Aug 24, 2020= at 1:12 PM Justin Richer <jricher@mi= t.edu> wrote:
      Denis, thanks for writing th= is up. I don=E2=80=99t think we want to get into the business of defining w= hat an API should do for service and capability discovery, especially since= there are a wide variety of API patterns and styles out there, each with t= heir own discovery principles. I agree with Dick that the right way to appr= oach this is likely to use the =E2=80=9CWWW-Authenticate=E2=80=9D header re= sponse, which is what I=E2=80=99ve proposed as a straw man in section 10.4 = of XYZ:

      =
      For use cases like yours where the client starts at the RS, = this makes a lot of sense and the RS can point the client toward the AS it = should be using, and even tell it what kind of thing it needs to ask for ne= xt. There=E2=80=99s a lot of work we can do there to make that robust and u= seful.

      But, just like AS discovery, I think that=E2=80= =99s an optimization for cases where that information isn=E2=80=99t known b= y some other means. It=E2=80=99s my stance that, wherever possible, discove= ry should be an optional add-on to let software optimize the experience, no= t something required for the protocol to work. =E2=80=9CDiscovery=E2=80=9D = and =E2=80=9Cregistration=E2=80=9D assume a mostly-static world, where sysa= dmins are making security decisions ahead of time and assigning identifiers= to those decisions. I think that if we take a step back and look at the fu= ndamentals of what we=E2=80=99re trying to solve here, we don=E2=80=99t act= ually need discovery or registration a lot of the time, and certainly not a= s add-ons like they are in OAuth 2.

      When I wr= ote XYZ, one of the goals was for it to be =E2=80=9Cdynamic first=E2=80=9D,= so that the client and server wouldn=E2=80=99t :need: to know anything abo= ut each other ahead of time in order for the core protocol to work. Now of = course, in many cases, the AS is only going to trust calls from keys that i= t=E2=80=99s seen as part of a static registration record, and a client is g= oing to be configured or programmed to only take actions that are available= at the AS it=E2=80=99s been written to talk to. But it=E2=80=99s important= to me that these cases are optimizations on the overall protocol, which (u= nlike OAuth) doesn=E2=80=99t assume a discovery or registration step happen= ed out of band first.=C2=A0

      In today=E2=80=99s wor= ld, we=E2=80=99ve got so many signals that software can send each other at = runtime that can be processed and likely trusted much more than a static di= scovery/registration ever could. The client can send over device posture, o= rganizational affiliation attestations, verifiable credentials of the curre= nt user (without the AS ever seeing the user), derived credentials that are= tied to some external trusted registry (think of a CA style model but for = more than certificates), or any number of other signals that people are usi= ng and building. None of these lend themselves to OAuth=E2=80=99s =E2=80=9C= client_id is required everywhere=E2=80=9D model, which was built around a n= otion of two web sites talking to each other. That=E2=80=99s why I think we= should not only be getting away from the discovery/registration mindset an= d towards a dynamic-first negotiated protocol which can, in turn, be optimi= zed in a secure and clean fashion.

      =C2=A0=E2=80=94= Justin

      On Aug 24, 2020, at 4:16= AM, Denis <deni= s.ietf@free.fr> wrote:

      =20

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      =

      Sections 3 and 3.7 from draft-hardt-xauth-prot= ocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/ht= ml/rfc7231#section-4.3.7).

      RFC 7231 mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
      =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the representation media type.=C2=A0 Although this specification does not define any use for such a payload, future extensions to HTTP
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

      =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

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

      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      --000000000000bef33905ada73533-- From nobody Tue Aug 25 02:37:53 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 D6E413A0BDA for ; Tue, 25 Aug 2020 02:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 jGjOTob5Qb-r for ; Tue, 25 Aug 2020 02:37:50 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7463A0BE4 for ; Tue, 25 Aug 2020 02:37:49 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d38 with ME id Kldm2300F2bcEcA03ldmMe; Tue, 25 Aug 2020 11:37:47 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 11:37:47 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: From: Denis Message-ID: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> Date: Tue, 25 Aug 2020 11:37:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7EDBBE08E80BB93B9F43D392" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 25 Aug 2020 09:37:52 -0000 This is a multi-part message in MIME format. --------------7EDBBE08E80BB93B9F43D392 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, A few arguments: * The 401 (Unauthorized) status code indicates that the request has not  been applied because it lacks valid authentication credentials for the target resource. Information about how to authenticate is NOT in the HTTP Authorization header. So it is not a discovery mechanism but, at best, a trial and error mechanism. * As already said, reading the documentation is one way, but making a real time inquiry is another way which is better for clients acting on behalf of a User. * If the OPTIONS method call can be used at the GS, it should not be forbidden to be used as well at the RS. The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User. Denis > A comment about an OPTIONS call being the first call in the protocol. > > While that is possible, I expect most use of the discovery will happen > by tooling rather than client software. IE, when developing against an > GS, the developers tool chain will check what the GS supports. > > On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt > wrote: > > Hi Denis > > While it is an interesting idea to use the OPTIONS method at the > RS, the standard way to indicate authentication mechanisms is with > a 401 HTTP response per > https://tools.ietf.org/html/rfc7235#section-3.1 > > And then information about how to authenticate may be in the HTTP > Authorization header. > > This allows an RS to respond to any request including an OPTIONS > method call. > > /Dick > > > ᐧ > > On Mon, Aug 24, 2020 at 1:16 AM Denis > wrote: > > Hi Dick*, > * > > The following comments have been elaborated after an analysis > of your draft: draft-hardt-xauth-protocol-13. > > *1 ) Authentication mechanisms discovery at the GS* > > Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are > proposing to support an HTTP OPTIONS request which would be > the first request > when talking to a GS. The goal is to be able to query the > authentication mechanisms supported by the GS. This would > indeed be very useful. > > The HTTP OPTIONS request has been first defined in RFC 2616 > and refined in RFC 7231 (see > https://tools.ietf.org/html/rfc7231#section-4.3.7). > > RFC 7231 mentions: > >       A standard format for such a representation is not > defined by this specification, but might be defined by future > extensions to HTTP. >       A client that generates an OPTIONS request containing a > payload body MUST send a valid Content-Type header field > describing >       the representation media type.Although this > specification does not define any use for such a payload, > future extensions to HTTP >       might use the OPTIONS body to make more detailed queries > about the target resource. > > RFC 7231 also mentions: > >       A server generating a successful response to OPTIONS > SHOULD send an header fields that might indicate optional > features >       implemented by the server and applicable to the target > resource, including potential extensions not defined by this > specification. > > However, two types of authentication are possible: user > authentication and client authentication. If both are > supported by the GS, it would be possible > to address this concern either by returning two lists of > authentication methods or even better by using two different > Content-Type header fields describing > the representation media type, since the client is knowing > whether it is acting or not on behalf of a User.* > * > > *2) Authentication mechanisms discovery at the RS* > > This HTTP OPTIONS request should also be supported by a RS. > When a client first contacts a RS, it does not necessarily > know the authentication > methods that are /currently/ supported by the RS. This means > that the same request as the one used for the GS should be > available for a RS as well. > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------7EDBBE08E80BB93B9F43D392 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Dick,

      A few arguments:
      • The 401 (Unauthorized) status code indicates that the request has not  been applied because it lacks valid authentication credentials for the target resource.
        Information about how to authenticate is NOT in the HTTP Authorization header. So it is not a discovery mechanism but, at best, a trial and error mechanism.

      • As already said, reading the documentation is one way, but making a real time inquiry is another way which is better for clients acting on behalf of a User.

      • If the OPTIONS method call can be used at the GS, it should not be forbidden to be used as well at the RS.
      The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User.

      Denis

      A comment about an OPTIONS call being the first call in the protocol.

      While that is possible, I expect most use of the discovery will happen by tooling rather than client software. IE, when developing against an GS, the developers tool chain will check what the GS supports.

      On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Denis

      While it is an interesting idea to use the OPTIONS method at the RS, the standard way to indicate authentication mechanisms is with a 401 HTTP response per

      And then information about how to authenticate may be in the HTTP Authorization header.

      This allows an RS to respond to any request including an OPTIONS method call.

      /Dick


      ᐧ

      On Mon, Aug 24, 2020 at 1:16 AM Denis <denis.ietf@free.fr> wrote:

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

            A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
            A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
            the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP
            might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

            A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
            implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

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


      --------------7EDBBE08E80BB93B9F43D392-- From nobody Tue Aug 25 03:36:20 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 1A5473A0C33 for ; Tue, 25 Aug 2020 03:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gpMXcI7HuAVQ for ; Tue, 25 Aug 2020 03:36:16 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF39A3A0C28 for ; Tue, 25 Aug 2020 03:36:15 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d38 with ME id KmcD2300J2bcEcA03mcD1j; Tue, 25 Aug 2020 12:36:13 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 12:36:13 +0200 X-ME-IP: 90.79.51.120 To: Justin Richer Cc: "txauth@ietf.org" References: <247CA426-CB07-482F-ADFB-B8CE8AC9D8E2@mit.edu> From: Denis Message-ID: Date: Tue, 25 Aug 2020 12:36:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <247CA426-CB07-482F-ADFB-B8CE8AC9D8E2@mit.edu> Content-Type: multipart/alternative; boundary="------------847498D987523B3D6B153F19" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 25 Aug 2020 10:36:19 -0000 This is a multi-part message in MIME format. --------------847498D987523B3D6B153F19 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, > Denis, thanks for writing this up. I don’t think we want to get into > the business of defining what an API should do for service and > capability discovery, > especially since there are a wide variety of API patterns and styles > out there, each with their own discovery principles. I agree with Dick > that the right way > to approach this is likely to use the “WWW-Authenticate” header > response, which is what I’ve proposed as a straw man in section 10.4 > of XYZ: > > https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.4 > Section 10.4 deals with an error case when making a call to RS without an access token, or with an invalid access token. It has nothing to do with either "Authentication mechanisms discovery" (nor with "API discovery"). > For use cases like yours where the client starts at the RS, this makes > a lot of sense and the RS can point the client toward the AS it should > be using, > and even tell it what kind of thing it needs to ask for next. There’s > a lot of work we can do there to make that robust and useful. Fine. > But, just like AS discovery, I think that’s an optimization for cases > where that information isn’t known by some other means.  ... or is not up-to-date any more. > It’s my stance that, wherever possible, discovery should be an > optional add-on to let software optimize the experience, not something > required for the protocol to work. I would guess that you are missing an important point: I am not simply considering the support of, one way or another, the concepts behind HATEOAS but in case where the client is acting on behalf of a user, a combination of both HATEOAS and User consent, i.e. knowing at the same time which actions that can be done and the access control characteristics associated with these actions (which is an aspect that is not addressed in HATEOAS). In such a case, the information sent by the RS would be used by the client to get the User Consent *and choices*. If you have comments on these topics, please send them using the thread "API discovery". > “Discovery” and “registration” assume a mostly-static world, where > sysadmins are making security decisions ahead of time and assigning > identifiers to those decisions. On the contrary, "discovery" is far from being static since it is done in real-time. > I think that if we take a step back and look at the fundamentals of > what we’re trying to solve here, we don’t actually need discovery or > registration a lot of the time, > and certainly not as add-ons like they are in OAuth 2. > > When I wrote XYZ, one of the goals was for it to be “dynamic first”, > so that the client and server wouldn’t :need: to know anything about > each other ahead of time > in order for the core protocol to work. > > Now of course, in many cases, the AS is only going to trust calls from > keys that it’s seen as part of a static registration record, and a > client is going to be configured > or programmed to only take actions that are available at the AS it’s > been written to talk to. But it’s important to me that these cases are > optimizations on the overall > protocol, which (unlike OAuth) doesn’t assume a discovery or > registration step happened out of band first. This is only one half of the story: this is an "AS centric" view. If only one AS is associated with a RS and the programmer knows it (which is a specific use case), then "API discovery" can be avoided when two web sites are talking to each other. Please consider this other thread, i.e. "Two comments on draft-richer-transactional-authz-06" to send your comments about the "AS centric" and the "RS centric" use cases. > In today’s world, we’ve got so many signals that software can send > each other at runtime that can be processed and likely trusted much > more than a static discovery/registration ever could. > The client can send over device posture, organizational affiliation > attestations, verifiable credentials of the current user (without the > AS ever seeing the user), derived credentials that are tied > to some external trusted registry (think of a CA style model but for > more than certificates), or any number of other signals that people > are using and building. None of these lend themselves > to OAuth’s “client_id is required everywhere” model, which was built > around a notion of two web sites talking to each other. I wonder why you are speaking of a "client_id" which is a topic that I have not addressed in any of the three recently threads that I have opened. > That’s why I think we should not only be getting away from the > discovery/registration mindset and towards a dynamic-first negotiated > protocol which can, in turn, > be optimized in a secure and clean fashion. Unfortunately, your conclusion (which is not crystal clear to me) is unrelated to the arguments you have exposed. Denis >  — Justin > >> On Aug 24, 2020, at 4:16 AM, Denis > > wrote: >> >> >> Hi Dick*, >> * >> >> The following comments have been elaborated after an analysis of your >> draft: draft-hardt-xauth-protocol-13. >> >> *1 ) Authentication mechanisms discovery at the GS* >> >> Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing >> to support an HTTP OPTIONS request which would be the first request >> when talking to a GS. The goal is to be able to query the >> authentication mechanisms supported by the GS. This would indeed be >> very useful. >> >> The HTTP OPTIONS request has been first defined in RFC 2616 and >> refined in RFC 7231 (see >> https://tools.ietf.org/html/rfc7231#section-4.3.7). >> >> RFC 7231 mentions: >> >> A standard format for such a representation is not defined by this >> specification, but might be defined by future extensions to HTTP. >>       A client that generates an OPTIONS request containing a payload >> body MUST send a valid Content-Type header field describing >>       the representation media type.Although this specification does >> not define any use for such a payload, future extensions to HTTP >>       might use the OPTIONS body to make more detailed queries about >> the target resource. >> >> RFC 7231 also mentions: >> >> A server generating a successful response to OPTIONS SHOULD send an >> header fields that might indicate optional features >>       implemented by the server and applicable to the target >> resource, including potential extensions not defined by this >> specification. >> >> However, two types of authentication are possible: user >> authentication and client authentication. If both are supported by >> the GS, it would be possible >> to address this concern either by returning two lists of >> authentication methods or even better by using two different >> Content-Type header fields describing >> the representation media type, since the client is knowing whether it >> is acting or not on behalf of a User.* >> * >> >> *2) Authentication mechanisms discovery at the RS* >> >> This HTTP OPTIONS request should also be supported by a RS. When a >> client first contacts a RS, it does not necessarily know the >> authentication >> methods that are /currently/ supported by the RS. This means that the >> same request as the one used for the GS should be available for a RS >> as well. >> >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --------------847498D987523B3D6B153F19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Justin,

      Denis, thanks for writing this up. I don’t think we want to get into the business of defining what an API should do for service and capability discovery,
      especially since there are a wide variety of API patterns and styles out there, each with their own discovery principles. I agree with Dick that the right way
      to approach this is likely to use the “WWW-Authenticate” header response, which is what I’ve proposed as a straw man in section 10.4 of XYZ:


      Section 10.4 deals with an error case when making a call to RS without an access token, or with an invalid access token.
      It has nothing to do with either "Authentication mechanisms discovery" (nor with "API discovery").

      For use cases like yours where the client starts at the RS, this makes a lot of sense and the RS can point the client toward the AS it should be using,
      and even tell it what kind of thing it needs to ask for next. There’s a lot of work we can do there to make that robust and useful.

      Fine.

      But, just like AS discovery, I think that’s an optimization for cases where that information isn’t known by some other means.

       ... or is not up-to-date any more.

      It’s my stance that, wherever possible, discovery should be an optional add-on to let software optimize the experience, not something required for the protocol to work.

      I would guess that you are missing an important point: I am not simply considering the support of, one way or another, the concepts behind HATEOAS
      but in case where the client is acting on behalf of a user, a combination of both       HATEOAS and User consent, i.e. knowing at the same time
      which actions that can be done and the access control characteristics associated with these actions (which is an aspect that is not addressed in HATEOAS).
      In such a case, the information sent by the RS would be used by the client to get the User Consent *and choices*.

      If you have comments on these topics, please send them using the thread "API discovery".

      “Discovery” and “registration” assume a mostly-static world, where sysadmins are making security decisions ahead of time and assigning identifiers to those decisions.

      On the contrary, "discovery" is far from being static since it is done in real-time.

      I think that if we take a step back and look at the fundamentals of what we’re trying to solve here, we don’t actually need discovery or registration a lot of the time,
      and certainly not as add-ons like they are in OAuth 2.

      When I wrote XYZ, one of the goals was for it to be “dynamic first”, so that the client and server wouldn’t :need: to know anything about each other ahead of time
      in order for the core protocol to work.

      Now of course, in many cases, the AS is only going to trust calls from keys that it’s seen as part of a static registration record, and a client is going to be configured
      or programmed to only take actions that are available at the AS it’s been written to talk to. But it’s important to me that these cases are optimizations on the overall
      protocol, which (unlike OAuth) doesn’t assume a discovery or registration step happened out of band first.

      This is only one half of the story: this is an "AS centric" view. If only one AS is associated with a RS and the programmer knows it (which is a specific use case), then
      "API discovery" can be avoided when two web sites are talking to each other. Please consider this other thread, i.e. "Two comments on draft-richer-transactional-authz-06"
      to send your comments about the "AS centric" and the "RS centric" use cases.

      In today’s world, we’ve got so many signals that software can send each other at runtime that can be processed and likely trusted much more than a static discovery/registration ever could.
      The client can send over device posture, organizational affiliation attestations, verifiable credentials of the current user (without the AS ever seeing the user), derived credentials that are tied
      to some external trusted registry (think of a CA style model but for more than certificates), or any number of other signals that people are using and building. None of these lend themselves
      to OAuth’s “client_id is required everywhere” model, which was built around a notion of two web sites talking to each other.

      I wonder why you are speaking of a "client_id" which is a topic that I have not addressed in any of the three recently threads that I have opened.

      That’s why I think we should not only be getting away from the discovery/registration mindset and towards a dynamic-first negotiated protocol which can, in turn,
      be optimized in a secure and clean fashion.

      Unfortunately, your conclusion (which is not crystal clear to me) is unrelated to the arguments you have exposed.

      Denis

       — Justin

      On Aug 24, 2020, at 4:16 AM, Denis <denis.ietf@free.fr> wrote:


      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

            A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
            A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
            the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP
            might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

            A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
            implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

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


      --------------847498D987523B3D6B153F19-- From nobody Tue Aug 25 08:54:16 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 F37173A0E51 for ; Tue, 25 Aug 2020 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 sazyaNZ7eupe for ; Tue, 25 Aug 2020 08:54:12 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 8DF763A0EE5 for ; Tue, 25 Aug 2020 08:54:12 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id c8so6701434lfh.9 for ; Tue, 25 Aug 2020 08:54:12 -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=jePiaHpGpucJ41DWmROd+5bQeO5VthvgFmvbhyxsOdc=; b=ItYXyKtdBxRZbE49zL4FMj49t68W7WfTuWNI/Me2QYo3UgTOXYddVCRXQn+6wsiZqf 6RK7rqDF2emtXcVbYkPpwmB0ButHh0D2ElcgmblKVL2+o9HlgoP1hlh/yZs5Mlu4F5Fq 2TyUweXCO8tdNg57dZGda7jcOEYUPVb8U2oqjRq+yuRjxhDR9lcdWlFfEWBSjXVvyw+/ qKmifdsCtMUUa6jQx3QuWa0BO799a0nrq87X8pHLyKtQ4ODtBCMO8RIPKdG+oiqNiWQU JG+T7UfhDi6KReJczChX51EMqiTAA3TAFp+WBkvfT3A3oZDGHD+fNRGEi64WG4HJeg7h NJtw== 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=jePiaHpGpucJ41DWmROd+5bQeO5VthvgFmvbhyxsOdc=; b=JZuzGdYRRtdS01prJCFGVkPjtW5nJ7YK1RVoKx/XfC3f1embt1py0pgiq+VjJQwUlw rzXBsTu93slpAzVY0ertw+2zT87PHahmTyGSymyAD3AdtxnxbQ1NLF8CG3SZbLTRVnXf kG2AjslK0kLPSyfKIwgOJOaK/ap/gWSBL49sn5NZSiddiv8a9JLCpmo0mXTAn1psjfez WGCyJOYhPy8DVBnLshS37igtiNeLtmZ22yykxyAINAVyzb5egFvaTvQhvQ36zrRmPOKN Ai3zXXhZ+9egucq4+cWZgr9bmFusD80CLguETkOuqIU9B/xCO8jkrqFDmALY7Icyxjl/ 0zsg== X-Gm-Message-State: AOAM532PYAHU/ZiykXGAQ/4SY1QhDboqdzh3BBAywvYZYUeB0X1xmYYP z4MgD7e68nFKjooe2BVvFVaRJDbBaTky78nCBr8= X-Google-Smtp-Source: ABdhPJyJueRQJWhj/8+rLj4Kvd1rCmaOWxL3XyiRcO25gkgP5WMssiguTt4D5MvMpcisX+dBxjDEQC8ve0PHUleHAaM= X-Received: by 2002:ac2:43c5:: with SMTP id u5mr5260292lfl.0.1598370850399; Tue, 25 Aug 2020 08:54:10 -0700 (PDT) MIME-Version: 1.0 References: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> In-Reply-To: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> From: Dick Hardt Date: Tue, 25 Aug 2020 08:53:34 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c1ec0505adb5b603" Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 25 Aug 2020 15:54:15 -0000 --000000000000c1ec0505adb5b603 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree, the 401 response is not the ideal architecture, but it works for any URI or method. What if the OPTIONS method itself requires authentication? How does the RS return how to authenticate? Does the RS need to support the OPTIONS method on all API endpoints? An OPTIONS method at the RS is not forbidden, but just like at the GS, OPTIONS is a general discovery mechanism, not just for authentication. As I have stated previously: - a real time query only works if the results are standardized. There are few standardized APIs or standardized "scopes". - there are a very wide set of choices on how the user can authenticate. I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don't see that as being in the core protocol. =E1=90=A7 On Tue, Aug 25, 2020 at 2:37 AM Denis wrote: > Hi Dick, > > A few arguments: > > - The 401 (Unauthorized) status code indicates that the request has > not been applied because it lacks valid authentication credentials fo= r the > target resource. > Information about how to authenticate is NOT in the HTTP Authorization > header. So it is not a discovery mechanism but, at best, a trial and e= rror > mechanism. > > - As already said, reading the documentation is one way, but making a > real time inquiry is another way which is better for clients acting on > behalf of a User. > > - If the OPTIONS method call can be used at the GS, it should not be > forbidden to be used as well at the RS. > > The missing point in draft-hardt-xauth-protocol-13 is the lack of > difference between an authentication made by the client application on it= s > own behalf or on behalf of a User. > > Denis > > A comment about an OPTIONS call being the first call in the protocol. > > While that is possible, I expect most use of the discovery will happen by > tooling rather than client software. IE, when developing against an GS, t= he > developers tool chain will check what the GS supports. > > On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt wrote: > >> Hi Denis >> >> While it is an interesting idea to use the OPTIONS method at the RS, the >> standard way to indicate authentication mechanisms is with a 401 HTTP >> response per >> https://tools.ietf.org/html/rfc7235#section-3.1 >> >> And then information about how to authenticate may be in the HTTP >> Authorization header. >> >> This allows an RS to respond to any request including an OPTIONS method >> call. >> >> /Dick >> >> >> =E1=90=A7 >> >> On Mon, Aug 24, 2020 at 1:16 AM Denis wrote: >> >>> Hi Dick >>> *, * >>> >>> The following comments have been elaborated after an analysis of your >>> draft: draft-hardt-xauth-protocol-13. >>> >>> *1 ) Authentication mechanisms discovery at the GS* >>> >>> Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to >>> support an HTTP OPTIONS request which would be the first request >>> when talking to a GS. The goal is to be able to query the authenticatio= n >>> mechanisms supported by the GS. This would indeed be very useful. >>> >>> The HTTP OPTIONS request has been first defined in RFC 2616 and refined >>> in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7). >>> >>> RFC 7231 mentions: >>> >>> A standard format for such a representation is not defined by thi= s >>> specification, but might be defined by future extensions to HTTP. >>> A client that generates an OPTIONS request containing a payload >>> body MUST send a valid Content-Type header field describing >>> the representation media type. Although this specification does >>> not define any use for such a payload, future extensions to HTTP >>> might use the OPTIONS body to make more detailed queries about th= e >>> target resource. >>> >>> RFC 7231 also mentions: >>> >>> A server generating a successful response to OPTIONS SHOULD send >>> an header fields that might indicate optional features >>> implemented by the server and applicable to the target resource, >>> including potential extensions not defined by this specification. >>> >>> However, two types of authentication are possible: user authentication >>> and client authentication. If both are supported by the GS, it would be >>> possible >>> to address this concern either by returning two lists of authentication >>> methods or even better by using two different Content-Type header field= s >>> describing >>> the representation media type, since the client is knowing whether it i= s >>> acting or not on behalf of a User. >>> >>> *2) Authentication mechanisms discovery at the RS* >>> >>> This HTTP OPTIONS request should also be supported by a RS. When a >>> client first contacts a RS, it does not necessarily know the authentica= tion >>> methods that are *currently* supported by the RS. This means that the >>> same request as the one used for the GS should be available for a RS as >>> well. >>> >>> Denis >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > --000000000000c1ec0505adb5b603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

      I agree, the 401 response is not the i= deal architecture, but it works for any URI or method. What if the OPTIONS = method itself requires authentication? How does the RS return how to authen= ticate? Does the RS need to support the OPTIONS method on all API endpoints= ?=C2=A0

      An OPTIONS method at the RS is not forbidden, b= ut just like at the GS, OPTIONS is a general discovery mechanism, not just = for authentication.=C2=A0

      As I have stated previously:

      - a real time query only works if the results are s= tandardized. There are few standardized APIs or standardized "scopes&q= uot;.

      -=C2=A0there are a very wide set of choices = on how the user can authenticate. I'm not saying GNAP should not suppor= t your model of the user authenticating somewhere other than the GS, but I = don't see that as being in the core protocol.=C2=A0

      3D"==E1=90=A7

      On Tue, Aug 25, 2020 at 2:37 AM Denis <<= a href=3D"mailto:denis.ietf@free.fr">denis.ietf@free.fr> wrote:
      <= /div>
      =20 =20 =20
      Hi Dick,

      A few arguments:
      • The 401 (Unauthorized) status code indicates that the request has not=C2=A0 been applied because it lacks valid authentication credentials for the target resource.
        Information about how to authenticate is NOT in the HTTP Authorization header. So it is not a discovery mechanism but, at best, a trial and error mechanism.

      • As already said, reading the documentation is one way, but making a real time inquiry is another way which is better for clients acting on behalf of a User.

      • If the OPTIONS method call can be used at the GS, it should not be forbidden to be used as well at the RS.
      The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User.

      Denis

      =20
      A comment about an OPTIONS call being the first call in the protocol.

      While that is possible, I expect most use of the discovery will happen by tooling rather than client software. IE, when developing against an GS, the developers tool chain will check what the GS supports.

      On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Denis

      While it is an interesting idea to use the OPTIONS method at the RS, the standard way to indicate authentication mechanisms is with a 401 HTTP response per

      And then information about how to authenticate may be in the HTTP Authorization header.

      This allows an RS to respond to any request including an OPTIONS method call.

      /Dick


      =3D""=E1=90=A7

      On Mon, Aug 24, 2020 at 1:16 AM Denis <denis.ietf@free.fr> wrote:

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-= xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7= ).

      RFC 7231 mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
      =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the representation media= type.=C2=A0 Although this specification does not define any use for such a payload, future extensions to HTTP
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 might use the OPTIONS bo= dy to make more detailed queries about the target resource.
      =

      RFC 7231 also mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implemented by the serve= r and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.      =

      Denis

      --
      TXAuth mailing list
      TXAuth@i= etf.org
      https://www.ietf.org/mailman/listinfo/txa= uth


      --000000000000c1ec0505adb5b603-- From nobody Tue Aug 25 09:18:40 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 DF0F93A0FE4 for ; Tue, 25 Aug 2020 09:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Egse8oxvh5gY for ; Tue, 25 Aug 2020 09:18:36 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024803A0F03 for ; Tue, 25 Aug 2020 09:18:35 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d22 with ME id KsJY2300L2bcEcA03sJZWG; Tue, 25 Aug 2020 18:18:34 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 18:18:34 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> From: Denis Message-ID: Date: Tue, 25 Aug 2020 18:18:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B6CC4CAA406B3A5FD8464708" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 25 Aug 2020 16:18:39 -0000 This is a multi-part message in MIME format. --------------B6CC4CAA406B3A5FD8464708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > I agree, the 401 response is not the ideal architecture, but it works > for any URI or method. > What if the OPTIONS method itself requires authentication? How does > the RS return how to authenticate? > Does the RS need to support the OPTIONS method on all API endpoints? Please remember that there are two different reasons to use the OPTIONS methods:  "Authentication mechanisms discovery" and "API discovery". The "Authentication mechanisms discovery"  does not require authentication : this is already stated in the draft. The RS returns how to authenticate in the same way that the GS does it, except that it may also indicate which ASs are appropriate and which attributes should be included into an access token. Since the OPTIONS method is used to support the User consent, it shall be supported on every API endpoint that requires a user consent. > An OPTIONS method at the RS is not forbidden, but just like at the GS, > OPTIONS is a general discovery mechanism, not just for authentication. Not exactly. There would clearly be two flavours of it : one for "Authentication mechanisms discovery" and another one "API discovery". > As I have stated previously: > > - a real time query only works if the results are standardized. There > are few standardized APIs or standardized "scopes". The suggestion is indeed to define return standardized parameters for each of these two flavours. > - there are a very wide set of choices on how the user can authenticate. > I'm not saying GNAP should not support your model of the user > authenticating somewhere other than the GS, but I don't see that as > being in the core protocol. Please look again at the major difference between "Authentication mechanisms discovery" and "API discovery". This question is once again whether an "AS centric" method is supported or a "RS centric" method is supported. Denis PS: Once again : "The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User". Any comment ? > ᐧ > > On Tue, Aug 25, 2020 at 2:37 AM Denis > wrote: > > Hi Dick, > > A few arguments: > > * The 401 (Unauthorized) status code indicates that the request > has not  been applied because it lacks valid authentication > credentials for the target resource. > Information about how to authenticate is NOT in the HTTP > Authorization header. So it is not a discovery mechanism but, > at best, a trial and error mechanism. > > * As already said, reading the documentation is one way, but > making a real time inquiry is another way which is better for > clients acting on behalf of a User. > > * If the OPTIONS method call can be used at the GS, it should > not be forbidden to be used as well at the RS. > > The missing point in draft-hardt-xauth-protocol-13 is the lack of > difference between an authentication made by the client > application on its own behalf or on behalf of a User. > > Denis > >> A comment about an OPTIONS call being the first call in the >> protocol. >> >> While that is possible, I expect most use of the discovery will >> happen by tooling rather than client software. IE, when >> developing against an GS, the developers tool chain will check >> what the GS supports. >> >> On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt > > wrote: >> >> Hi Denis >> >> While it is an interesting idea to use the OPTIONS method at >> the RS, the standard way to indicate authentication >> mechanisms is with a 401 HTTP response per >> https://tools.ietf.org/html/rfc7235#section-3.1 >> >> And then information about how to authenticate may be in the >> HTTP Authorization header. >> >> This allows an RS to respond to any request including an >> OPTIONS method call. >> >> /Dick >> >> >> ᐧ >> >> On Mon, Aug 24, 2020 at 1:16 AM Denis > > wrote: >> >> Hi Dick*, >> * >> >> The following comments have been elaborated after an >> analysis of your draft: draft-hardt-xauth-protocol-13. >> >> *1 ) Authentication mechanisms discovery at the GS* >> >> Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are >> proposing to support an HTTP OPTIONS request which would >> be the first request >> when talking to a GS. The goal is to be able to query the >> authentication mechanisms supported by the GS. This would >> indeed be very useful. >> >> The HTTP OPTIONS request has been first defined in RFC >> 2616 and refined in RFC 7231 (see >> https://tools.ietf.org/html/rfc7231#section-4.3.7). >> >> RFC 7231 mentions: >> >> A standard format for such a representation is not >> defined by this specification, but might be defined by >> future extensions to HTTP. >> A client that generates an OPTIONS request containing a >> payload body MUST send a valid Content-Type header field >> describing >>       the representation media type.Although this >> specification does not define any use for such a payload, >> future extensions to HTTP >>       might use the OPTIONS body to make more detailed >> queries about the target resource. >> >> RFC 7231 also mentions: >> >> A server generating a successful response to OPTIONS >> SHOULD send an header fields that might indicate optional >> features >>       implemented by the server and applicable to the >> target resource, including potential extensions not >> defined by this specification. >> >> However, two types of authentication are possible: user >> authentication and client authentication. If both are >> supported by the GS, it would be possible >> to address this concern either by returning two lists of >> authentication methods or even better by using two >> different Content-Type header fields describing >> the representation media type, since the client is >> knowing whether it is acting or not on behalf of a User.* >> * >> >> *2) Authentication mechanisms discovery at the RS* >> >> This HTTP OPTIONS request should also be supported by a >> RS. When a client first contacts a RS, it does not >> necessarily know the authentication >> methods that are /currently/ supported by the RS. This >> means that the same request as the one used for the GS >> should be available for a RS as well. >> >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --------------B6CC4CAA406B3A5FD8464708 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Dick,
      I agree, the 401 response is not the ideal architecture, but it works for any URI or method.
      What if the OPTIONS method itself requires authentication? How does the RS return how to authenticate?
      Does the RS need to support the OPTIONS method on all API endpoints?

      Please remember that there are two different reasons to use the OPTIONS methods:  "Authentication mechanisms discovery" and "API discovery".
      The       "Authentication mechanisms discovery"  does not require authentication : this is already stated in the draft.

      The RS       returns how to authenticate in the same way that the GS does it, except that it may also indicate which ASs are appropriate and which attributes
      should be included into an access token.

      Since the OPTIONS method is used to support the User consent, it shall be supported on every API endpoint that requires a user consent.

      An OPTIONS method at the RS is not forbidden, but just like at the GS, OPTIONS is a general discovery mechanism, not just for authentication.

      Not exactly. There would clearly be two flavours of it : one for "Authentication mechanisms discovery" and another one "API discovery".

      As I have stated previously:

      - a real time query only works if the results are standardized. There are few standardized APIs or standardized "scopes".

      The suggestion is indeed to define return standardized parameters for each of these two flavours.

      - there are a very wide set of choices on how the user can authenticate.
      I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don't see that as being in the core protocol.

      Please look again at the major difference between "Authentication mechanisms discovery" and "API discovery". This question is once again
      whether an "AS centric" method is supported or a "RS centric" method is supported.

      Denis


      PS: Once again : "The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application
      on its own behalf or on behalf of a User". Any comment ?


      ᐧ

      On Tue, Aug 25, 2020 at 2:37 AM Denis <denis.ietf@free.fr> wrote:
      Hi Dick,

      A few arguments:
      • The 401 (Unauthorized) status code indicates that the request has not  been applied because it lacks valid authentication credentials for the target resource.
        Information about how to authenticate is NOT in the HTTP Authorization header. So it is not a discovery mechanism but, at best, a trial and error mechanism.

      • As already said, reading the documentation is one way, but making a real time inquiry is another way which is better for clients acting on behalf of a User.

      • If the OPTIONS method call can be used at the GS, it should not be forbidden to be used as well at the RS.
      The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User.

      Denis

      A comment about an OPTIONS call being the first call in the protocol.

      While that is possible, I expect most use of the discovery will happen by tooling rather than client software. IE, when developing against an GS, the developers tool chain will check what the GS supports.

      On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Denis

      While it is an interesting idea to use the OPTIONS method at the RS, the standard way to indicate authentication mechanisms is with a 401 HTTP response per

      And then information about how to authenticate may be in the HTTP Authorization header.

      This allows an RS to respond to any request including an OPTIONS method call.

      /Dick


      ᐧ

      On Mon, Aug 24, 2020 at 1:16 AM Denis <denis.ietf@free.fr> wrote:

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

            A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
            A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
            the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP
            might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

            A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
            implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

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



      --------------B6CC4CAA406B3A5FD8464708-- From nobody Tue Aug 25 09:34:26 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 60BDC3A0F33 for ; Tue, 25 Aug 2020 09:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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 x5NgRcqm1ZoW for ; Tue, 25 Aug 2020 09:34:22 -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 C22F33A0F2C for ; Tue, 25 Aug 2020 09:34:21 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id w14so14558895ljj.4 for ; Tue, 25 Aug 2020 09:34:21 -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=HkN2KGXiPG7tQ+PuAVCLmKP5+fo37nA6V2FiRp7A+Fo=; b=ZWTTw5wDFvkdiOPL1j2aWgZ9h2aQ79txwocHWQmiS1FsEyR2CxpJXoHClAIJFKyeks T3QkXV94p7iEx3T871WA4k9c0Gh6/+jcdHwoYnovt2bgAN3wsasH0DmZwBhZ2GADDUfi ZgG6SO9UrHFAO53dAu2smmcAFnToZkcsQoEUJB+Aj7dwZ+MkOmWz5pF79qXICgslHVWB YlEjOIAe6AyZrWNC5psFIsI4y59n/j/lNxfgeRH/TVe7RM2fuJ3TIH6p0Gs8rIzcpdJ0 BQKlI9As8sbrZSjxxTlgEyLZZWrGwa6F4KOL/6hYaPOCudXMyVC9NyKmxEw0+418Ee9Z UyFw== 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=HkN2KGXiPG7tQ+PuAVCLmKP5+fo37nA6V2FiRp7A+Fo=; b=LFXtPp8GhbFjdjokE5QXv8uW92xalDq/0Ufr2JNRhyzhJtDJE33Gs3hv1HOj/BKHFP TKO98MHMNZyXAoeENW1mF/lu1bCyui3jsfZzYHdBKzWI9s7PAhXj2Ank7/cXqNiiPxLO qvZ50YQfJ/5Gpmy9FoAip1leUWTzCP8VXeNCdN9lOfdH0Bn3U8MuuBl1vaWYUhbEidlH hh8naxw+UL7G9rWDg3VZcQ7g5G/IP/I3UC+FITM1gYJHGb7+zOh96R18DGsHIbRsWZm2 fo3nF8h0CnMxVq870jVXiUplbCwPrOJBfIh1HKRehAgLgJ0dEENNVlMMjzInYxwEjGiz Fd8g== X-Gm-Message-State: AOAM530PBCZ4scg+KIEDPLM7HhYjyxMQVFF8xWlPdjrssGzrlKEtd8TP LwxLTpSlxH3lUftpMZnss1Qe6zPZUtJL0rw+qGE= X-Google-Smtp-Source: ABdhPJx88uXsdeFER8HSFbBJ9laehFbjpV1tzfBtX4ggJWhQXQlJ4PpXxkjjJEzd9ONWl0tV2NJousRTM4+v24tzhQY= X-Received: by 2002:a2e:2283:: with SMTP id i125mr5183786lji.142.1598373258365; Tue, 25 Aug 2020 09:34:18 -0700 (PDT) MIME-Version: 1.0 References: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> In-Reply-To: From: Dick Hardt Date: Tue, 25 Aug 2020 09:33:42 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000048929e05adb6461f" Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 25 Aug 2020 16:34:24 -0000 --00000000000048929e05adb6461f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I view unauthenticated OPTIONS calls to the GS returning what is available when unauthenticated. Client authentication mechanisms MAY be returned, but are not required to be returned by the GS. Your concept of being RS centric is interesting, and sheds light on the features you are requesting. There are many aspects of that to standardize, and contrary to a GS centric view, I don't know of common patterns to examine to see what has worked, and what has not worked. I do see how an RS centric model could work with the current GNAP protocol -- but I am strongly against GNAP *only* being RS centric. In my use cases, I have no need for an RS. wrt. user authentication, my response was - there are a very wide set of choices on how the user can authenticate. I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don't see that as being in the core protocol. Your response does not seem related to user authentication. /Dick On Tue, Aug 25, 2020 at 9:18 AM Denis wrote: > Hi Dick, > > I agree, the 401 response is not the ideal architecture, but it works for > any URI or method. > What if the OPTIONS method itself requires authentication? How does the R= S > return how to authenticate? > Does the RS need to support the OPTIONS method on all API endpoints? > > Please remember that there are two different reasons to use the OPTIONS > methods: "Authentication mechanisms discovery" and "API discovery". > The "Authentication mechanisms discovery" does not require > authentication : this is already stated in the draft. > > The RS returns how to authenticate in the same way that the GS does it, > except that it may also indicate which ASs are appropriate and which > attributes > should be included into an access token. > > Since the OPTIONS method is used to support the User consent, it shall be > supported on every API endpoint that requires a user consent. > > An OPTIONS method at the RS is not forbidden, but just like at the GS, > OPTIONS is a general discovery mechanism, not just for authentication. > > Not exactly. There would clearly be two flavours of it : one for > "Authentication mechanisms discovery" and another one "API discovery". > > As I have stated previously: > > - a real time query only works if the results are standardized. There are > few standardized APIs or standardized "scopes". > > The suggestion is indeed to define return standardized parameters for eac= h > of these two flavours. > > - there are a very wide set of choices on how the user can authenticate. > I'm not saying GNAP should not support your model of the user > authenticating somewhere other than the GS, but I don't see that as being > in the core protocol. > > Please look again at the major difference between "Authentication > mechanisms discovery" and "API discovery". This question is once again > whether an "AS centric" method is supported or a "RS centric" method is > supported. > > Denis > > > PS: Once again : "The missing point in draft-hardt-xauth-protocol-13 is > the lack of difference between an authentication made by the client > application > on its own behalf or on behalf of a User". Any comment ? > > > =E1=90=A7 > > On Tue, Aug 25, 2020 at 2:37 AM Denis wrote: > >> Hi Dick, >> >> A few arguments: >> >> - The 401 (Unauthorized) status code indicates that the request has >> not been applied because it lacks valid authentication credentials f= or the >> target resource. >> Information about how to authenticate is NOT in the HTTP >> Authorization header. So it is not a discovery mechanism but, at best= , a >> trial and error mechanism. >> >> - As already said, reading the documentation is one way, but making a >> real time inquiry is another way which is better for clients acting o= n >> behalf of a User. >> >> - If the OPTIONS method call can be used at the GS, it should not be >> forbidden to be used as well at the RS. >> >> The missing point in draft-hardt-xauth-protocol-13 is the lack of >> difference between an authentication made by the client application on i= ts >> own behalf or on behalf of a User. >> >> Denis >> >> A comment about an OPTIONS call being the first call in the protocol. >> >> While that is possible, I expect most use of the discovery will happen b= y >> tooling rather than client software. IE, when developing against an GS, = the >> developers tool chain will check what the GS supports. >> >> On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt wrote: >> >>> Hi Denis >>> >>> While it is an interesting idea to use the OPTIONS method at the RS, th= e >>> standard way to indicate authentication mechanisms is with a 401 HTTP >>> response per >>> https://tools.ietf.org/html/rfc7235#section-3.1 >>> >>> And then information about how to authenticate may be in the HTTP >>> Authorization header. >>> >>> This allows an RS to respond to any request including an OPTIONS method >>> call. >>> >>> /Dick >>> >>> >>> =E1=90=A7 >>> >>> On Mon, Aug 24, 2020 at 1:16 AM Denis wrote: >>> >>>> Hi Dick >>>> *, * >>>> >>>> The following comments have been elaborated after an analysis of your >>>> draft: draft-hardt-xauth-protocol-13. >>>> >>>> *1 ) Authentication mechanisms discovery at the GS* >>>> >>>> Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to >>>> support an HTTP OPTIONS request which would be the first request >>>> when talking to a GS. The goal is to be able to query the >>>> authentication mechanisms supported by the GS. This would indeed be ve= ry >>>> useful. >>>> >>>> The HTTP OPTIONS request has been first defined in RFC 2616 and refine= d >>>> in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7). >>>> >>>> RFC 7231 mentions: >>>> >>>> A standard format for such a representation is not defined by >>>> this specification, but might be defined by future extensions to HTTP. >>>> A client that generates an OPTIONS request containing a payload >>>> body MUST send a valid Content-Type header field describing >>>> the representation media type. Although this specification does >>>> not define any use for such a payload, future extensions to HTTP >>>> might use the OPTIONS body to make more detailed queries about >>>> the target resource. >>>> >>>> RFC 7231 also mentions: >>>> >>>> A server generating a successful response to OPTIONS SHOULD send >>>> an header fields that might indicate optional features >>>> implemented by the server and applicable to the target resource, >>>> including potential extensions not defined by this specification. >>>> >>>> However, two types of authentication are possible: user authentication >>>> and client authentication. If both are supported by the GS, it would b= e >>>> possible >>>> to address this concern either by returning two lists of authenticatio= n >>>> methods or even better by using two different Content-Type header fiel= ds >>>> describing >>>> the representation media type, since the client is knowing whether it >>>> is acting or not on behalf of a User. >>>> >>>> *2) Authentication mechanisms discovery at the RS* >>>> >>>> This HTTP OPTIONS request should also be supported by a RS. When a >>>> client first contacts a RS, it does not necessarily know the authentic= ation >>>> methods that are *currently* supported by the RS. This means that the >>>> same request as the one used for the GS should be available for a RS a= s >>>> well. >>>> >>>> Denis >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > =E1=90=A7 --00000000000048929e05adb6461f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      I view unauthenticated OPTIONS calls to t= he GS returning what is available when unauthenticated. Client authenticati= on mechanisms MAY be returned, but are not required to be returned by the G= S.

      Your concept of being RS centric is= interesting, and sheds light on the features you are requesting. There are= many aspects of that to standardize, and contrary to a GS centric view, I = don't know of common patterns to examine to see what has worked, and wh= at has not worked. I do see how an RS centric model could work with the cur= rent GNAP protocol -- but I am strongly against GNAP *only* being RS centri= c. In my use cases, I have=C2=A0no need for an RS.

      wrt. user authentication, my response was

      -=C2=A0there are a= very wide set of choices on how the user can authenticate.
      I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don'= t see that as being in the core protocol.

      Your response does not seem related to user authentication.<= /div>

      /Dick

      On Tue, Aug 25, 2020 at 9:18 AM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20
      Hi Dick,
      I agree, the 401 response is not the ideal architecture, but it works for any URI or method.
      What if the OPTIONS method itself requires authentication? How does the RS return how to authenticate?
      Does the RS need to support the OPTIONS method on all API endpoints?

      Please remember that there are two different reasons to use the OPTIONS methods:=C2=A0 "Authentication mech= anisms discovery" and "API discovery".
      The       "Authentication mechanisms discovery"=C2=A0 does not require authentication : this is alr= eady stated in the draft.

      The RS       returns how to authenticate in the same way that the GS does it, except that it may also indicate which ASs are appropriate and which attributes
      should be included into an access token.

      Since the OPTIONS method is used to support the User consent, it shall be supported on every API endpoint that requires a user consent.

      An OPTIONS method at the RS is not forbidden, but just like at the GS, OPTIONS is a general discovery mechanism, not just for authentication.

      Not exactly. There would clearly be two flavours of it : one for "Authentication mechanisms discovery&= quot; and another one "API discovery".

      As I have stated previously:

      - a real time query only works if the results are standardized. There are few standardized APIs or standardized "scopes".

      The suggestion is indeed to define return standardized parameters for each of these two flavours.

      -=C2=A0there are a very wide set of choic= es on how the user can authenticate.
      I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don'= t see that as being in the core protocol.

      Please look again at the major difference between "Authentication mechanisms discovery" and "A= PI discovery". This question is once again
      whether an "AS centric" method is supported or a "RS= centric" method is supported.

      Denis


      PS: Once again : "The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application
      on its own behalf or on behalf of a User". Any comment ?


      3D""==E1=90=A7

      On Tue, Aug 25, 2020 at 2:37 AM Denis <denis.ietf@free.fr> wrote:
      Hi Dick,

      A few arguments:
      • The 401 (Unauthorized) status code indicates that the request has not=C2=A0 been applied because it lacks valid authentication credentials for the target resource.
        Information about how to authenticate is NOT in the HTTP Authorization header. So it is not a discovery mechanism but, at best, a trial and error mechanism.

      • As already said, reading the documentation is one way, but making a real time inquiry is another way which is better for clients acting on behalf of a User.

      • If the OPTIONS method call can be used at the GS, it should not be forbidden to be used as well at the RS.
      The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User.

      Denis

      A comment about an OPTIONS call being the first call in the protocol.

      While that is possible, I expect most use of the discovery will happen by tooling rather than client software. IE, when developing against an GS, the developers tool chain will check what the GS supports.

      On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Denis

      While it is an interesting idea to use the OPTIONS method at the RS, the standard way to indicate authentication mechanisms is with a 401 HTTP response per

      And then information about how to authenticate may be in the HTTP Authorization header.

      This allows an RS to respond to any request including an OPTIONS method call.

      /Dick


      <= img alt=3D"" style=3D"width: 0px; max-height: 0px; overflow: hidden;" src= =3D"https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3D866e3144-f05a-4803-b002-df630cb926fd">= =E1=90=A7

      On Mon, Aug 24, 2020 at 1:16 AM Denis <denis.ietf@free.fr> wrote:

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from dr= aft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://to= ols.ietf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
      = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the representati= on media type.=C2=A0 Although this specification does not define any use for such a payload, future extensions to HTTP
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 might use the OP= TIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

      =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implemented by t= he server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

      --
      TXAuth mailing list
      = TXAuth@ietf.org
      https://www.ietf.org/mailman/listi= nfo/txauth



      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      3D""= =E1=90=A7
      --00000000000048929e05adb6461f-- From nobody Tue Aug 25 10:38:16 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 DD0F93A107F for ; Tue, 25 Aug 2020 10:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Jh-44hu4w-ud for ; Tue, 25 Aug 2020 10:38:12 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0B23A107D for ; Tue, 25 Aug 2020 10:38:11 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d05 with ME id Kte82300G2bcEcA03te9Q0; Tue, 25 Aug 2020 19:38:09 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 25 Aug 2020 19:38:09 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: "txauth@ietf.org" References: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> From: Denis Message-ID: <3e683ddf-1bc6-d8b2-2433-ae8fec18d2cb@free.fr> Date: Tue, 25 Aug 2020 19:38:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DE088F9D0F19F60E8DC96A4C" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 25 Aug 2020 17:38:15 -0000 This is a multi-part message in MIME format. --------------DE088F9D0F19F60E8DC96A4C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dick, > I view unauthenticated OPTIONS calls to the GS returning what is > available when unauthenticated. Yes, if the call is made on the root URL. > Client authentication mechanisms MAY be returned, but are not required > to be returned by the GS. ... or by the RS. :-) > Your concept of being RS centric is interesting, and sheds light on > the features you are requesting. There are many aspects of that to > standardize, > and contrary to a GS centric view, I don't know of common patterns to > examine to see what has worked, and what has not worked. I do see how > an RS centric model could work with the current GNAP protocol. Really ? I believe that the /current /GNAP protocol would need to be modified. > -- but I am strongly against GNAP *only* being RS centric. In my use > cases, I have no need for an RS. You are pushing onan open door. I already wrote on the thread "Two comments on draft-richer-transactional-authz-06": There are two cases to consider, one of them is "AS centric" while the other one is "RS centric". (...)  These two use cases should be supported. > wrt. user authentication, my response was > > - there are a very wide set of choices on how the user can > authenticate. > I'm not saying GNAP should not support your model of the user > authenticating somewhere other than the GS, but I don't see that > as being in the core protocol. > > Your response does not seem related to user authentication. As soon as there is a User choice which requires a User consent, I see a need to support an OPTIONS call. Denis PS. I will be away from my desk from tomorrow until the end of the week, so don't expect replies during that time window. > > /Dick > > On Tue, Aug 25, 2020 at 9:18 AM Denis > wrote: > > Hi Dick, > >> I agree, the 401 response is not the ideal architecture, but it >> works for any URI or method. >> What if the OPTIONS method itself requires authentication? How >> does the RS return how to authenticate? >> Does the RS need to support the OPTIONS method on all API endpoints? > > Please remember that there are two different reasons to use the > OPTIONS methods: "Authentication mechanisms discovery" and "API > discovery". > The "Authentication mechanisms discovery"  does not require > authentication : this is already stated in the draft. > > The RS returns how to authenticate in the same way that the GS > does it, except that it may also indicate which ASs are > appropriate and which attributes > should be included into an access token. > > Since the OPTIONS method is used to support the User consent, it > shall be supported on every API endpoint that requires a user consent. > >> An OPTIONS method at the RS is not forbidden, but just like at >> the GS, OPTIONS is a general discovery mechanism, not just for >> authentication. > > Not exactly. There would clearly be two flavours of it : one for > "Authentication mechanisms discovery" and another one "API discovery". > >> As I have stated previously: >> >> - a real time query only works if the results are standardized. >> There are few standardized APIs or standardized "scopes". > > The suggestion is indeed to define return standardized parameters > for each of these two flavours. > >> - there are a very wide set of choices on how the user can >> authenticate. >> I'm not saying GNAP should not support your model of the user >> authenticating somewhere other than the GS, but I don't see that >> as being in the core protocol. > > Please look again at the major difference between "Authentication > mechanisms discovery" and "API discovery". This question is once > again > whether an "AS centric" method is supported or a "RS centric" > method is supported. > > Denis > > > PS: Once again : "The missing point in > draft-hardt-xauth-protocol-13 is the lack of difference between an > authentication made by the client application > on its own behalf or on behalf of a User". Any comment ? > > >> ᐧ >> >> On Tue, Aug 25, 2020 at 2:37 AM Denis > > wrote: >> >> Hi Dick, >> >> A few arguments: >> >> * The 401 (Unauthorized) status code indicates that the >> request has not  been applied because it lacks valid >> authentication credentials for the target resource. >> Information about how to authenticate is NOT in the HTTP >> Authorization header. So it is not a discovery mechanism >> but, at best, a trial and error mechanism. >> >> * As already said, reading the documentation is one way, >> but making a real time inquiry is another way which is >> better for clients acting on behalf of a User. >> >> * If the OPTIONS method call can be used at the GS, it >> should not be forbidden to be used as well at the RS. >> >> The missing point in draft-hardt-xauth-protocol-13 is the >> lack of difference between an authentication made by the >> client application on its own behalf or on behalf of a User. >> >> Denis >> >>> A comment about an OPTIONS call being the first call in the >>> protocol. >>> >>> While that is possible, I expect most use of the discovery >>> will happen by tooling rather than client software. IE, when >>> developing against an GS, the developers tool chain will >>> check what the GS supports. >>> >>> On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt >>> > wrote: >>> >>> Hi Denis >>> >>> While it is an interesting idea to use the OPTIONS >>> method at the RS, the standard way to indicate >>> authentication mechanisms is with a 401 HTTP response per >>> https://tools.ietf.org/html/rfc7235#section-3.1 >>> >>> And then information about how to authenticate may be in >>> the HTTP Authorization header. >>> >>> This allows an RS to respond to any request including an >>> OPTIONS method call. >>> >>> /Dick >>> >>> >>> ᐧ >>> >>> On Mon, Aug 24, 2020 at 1:16 AM Denis >>> > wrote: >>> >>> Hi Dick*, >>> * >>> >>> The following comments have been elaborated after an >>> analysis of your draft: draft-hardt-xauth-protocol-13. >>> >>> *1 ) Authentication mechanisms discovery at the GS* >>> >>> Sections 3 and 3.7 from >>> draft-hardt-xauth-protocol-13 are proposing to >>> support an HTTP OPTIONS request which would be the >>> first request >>> when talking to a GS. The goal is to be able to >>> query the authentication mechanisms supported by the >>> GS. This would indeed be very useful. >>> >>> The HTTP OPTIONS request has been first defined in >>> RFC 2616 and refined in RFC 7231 (see >>> https://tools.ietf.org/html/rfc7231#section-4.3.7). >>> >>> RFC 7231 mentions: >>> >>>       A standard format for such a representation is >>> not defined by this specification, but might be >>> defined by future extensions to HTTP. >>>       A client that generates an OPTIONS request >>> containing a payload body MUST send a valid >>> Content-Type header field describing >>>       the representation media type.Although this >>> specification does not define any use for such a >>> payload, future extensions to HTTP >>>       might use the OPTIONS body to make more >>> detailed queries about the target resource. >>> >>> RFC 7231 also mentions: >>> >>>       A server generating a successful response to >>> OPTIONS SHOULD send an header fields that might >>> indicate optional features >>>       implemented by the server and applicable to >>> the target resource, including potential extensions >>> not defined by this specification. >>> >>> However, two types of authentication are possible: >>> user authentication and client authentication. If >>> both are supported by the GS, it would be possible >>> to address this concern either by returning two >>> lists of authentication methods or even better by >>> using two different Content-Type header fields >>> describing >>> the representation media type, since the client is >>> knowing whether it is acting or not on behalf of a >>> User.* >>> * >>> >>> *2) Authentication mechanisms discovery at the RS* >>> >>> This HTTP OPTIONS request should also be supported >>> by a RS. When a client first contacts a RS, it does >>> not necessarily know the authentication >>> methods that are /currently/ supported by the RS. >>> This means that the same request as the one used for >>> the GS should be available for a RS as well. >>> >>> Denis >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > ᐧ --------------DE088F9D0F19F60E8DC96A4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Hi Dick,

      I view unauthenticated OPTIONS calls to the GS returning what is available when unauthenticated.

      Yes, if the call is made on the root URL.

      Client authentication mechanisms MAY be returned, but are not required to be returned by the GS.

      ... or by the RS. :-)

      Your concept of being RS centric is interesting, and sheds light on the features you are requesting. There are many aspects of that to standardize,
      and contrary to a GS centric view, I don't know of common patterns to examine to see what has worked, and what has not worked. I do see how
      an RS centric model could work with the current GNAP protocol.

      Really ? I believe that the current GNAP protocol would need to be modified.

      -- but I am strongly against GNAP *only* being RS centric. In my use cases, I have no need for an RS.

      You are pushing on an open door. I already wrote on the thread "Two comments on draft-richer-transactional-authz-06":

      There are two cases to consider, one of them is "AS centric" while the other one is "RS centric".
      (...)  These two use cases should be supported.

      wrt. user authentication, my response was

      - there are a very wide set of choices on how the user can authenticate.
      I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don't see that as being in the core protocol.

      Your response does not seem related to user authentication.

      As soon as there is a User choice which requires a User consent, I see a need to support an OPTIONS call.

      Denis

      PS. I will be away from my desk from tomorrow until the end of the week, so don't expect replies during that time window.


      /Dick

      On Tue, Aug 25, 2020 at 9:18 AM Denis <denis.ietf@free.fr> wrote:
      Hi Dick,
      I agree, the 401 response is not the ideal architecture, but it works for any URI or method.
      What if the OPTIONS method itself requires authentication? How does the RS return how to authenticate?
      Does the RS need to support the OPTIONS method on all API endpoints?

      Please remember that there are two different reasons to use the OPTIONS methods:  "Authentication mechanisms discovery" and "API discovery".
      The       "Authentication mechanisms discovery"  does not require authentication : this is already stated in the draft.

      The RS       returns how to authenticate in the same way that the GS does it, except that it may also indicate which ASs are appropriate and which attributes
      should be included into an access token.

      Since the OPTIONS method is used to support the User consent, it shall be supported on every API endpoint that requires a user consent.

      An OPTIONS method at the RS is not forbidden, but just like at the GS, OPTIONS is a general discovery mechanism, not just for authentication.

      Not exactly. There would clearly be two flavours of it : one for "Authentication mechanisms discovery" and another one "API discovery".

      As I have stated previously:

      - a real time query only works if the results are standardized. There are few standardized APIs or standardized "scopes".

      The suggestion is indeed to define return standardized parameters for each of these two flavours.

      - there are a very wide set of choices on how the user can authenticate.
      I'm not saying GNAP should not support your model of the user authenticating somewhere other than the GS, but I don't see that as being in the core protocol.

      Please look again at the major difference between "Authentication mechanisms discovery" and "API discovery". This question is once again
      whether an "AS centric" method is supported or a "RS centric" method is supported.

      Denis


      PS: Once again : "The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application
      on its own behalf or on behalf of a User". Any comment ?


      ᐧ

      On Tue, Aug 25, 2020 at 2:37 AM Denis <denis.ietf@free.fr> wrote:
      Hi Dick,

      A few arguments:
      • The 401 (Unauthorized) status code indicates that the request has not  been applied because it lacks valid authentication credentials for the target resource.
        Information about how to authenticate is NOT in the HTTP Authorization header. So it is not a discovery mechanism but, at best, a trial and error mechanism.

      • As already said, reading the documentation is one way, but making a real time inquiry is another way which is better for clients acting on behalf of a User.

      • If the OPTIONS method call can be used at the GS, it should not be forbidden to be used as well at the RS.
      The missing point in draft-hardt-xauth-protocol-13 is the lack of difference between an authentication made by the client application on its own behalf or on behalf of a User.

      Denis

      A comment about an OPTIONS call being the first call in the protocol.

      While that is possible, I expect most use of the discovery will happen by tooling rather than client software. IE, when developing against an GS, the developers tool chain will check what the GS supports.

      On Mon, Aug 24, 2020 at 9:05 AM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Denis

      While it is an interesting idea to use the OPTIONS method at the RS, the standard way to indicate authentication mechanisms is with a 401 HTTP response per

      And then information about how to authenticate may be in the HTTP Authorization header.

      This allows an RS to respond to any request including an OPTIONS method call.

      /Dick


      ᐧ

      On Mon, Aug 24, 2020 at 1:16 AM Denis <denis.ietf@free.fr> wrote:

      Hi Dick,

      The following comments have been elaborated after an analysis of your draft: draft-hardt-xauth-protocol-13.

      1 ) Authentication mechanisms discovery at the GS

      Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing to support an HTTP OPTIONS request which would be the first request
      when talking to a GS. The goal is to be able to query the authentication mechanisms supported by the GS. This would indeed be very useful.

      The HTTP OPTIONS request has been first defined in RFC 2616 and refined in RFC 7231 (see https://tools.ietf.org/html/rfc7231#section-4.3.7).

      RFC 7231 mentions:

            A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
            A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing
            the representation media type.  Although this specification does not define any use for such a payload, future extensions to HTTP
            might use the OPTIONS body to make more detailed queries about the target resource.

      RFC 7231 also mentions:

            A server generating a successful response to OPTIONS SHOULD send an header fields that might indicate optional features
            implemented by the server and applicable to the target resource, including potential extensions not defined by this specification.

      However, two types of authentication are possible: user authentication and client authentication. If both are supported by the GS, it would be possible
      to address this concern either by returning two lists of authentication methods or even better by using two different Content-Type header fields describing
      the representation media type, since the client is knowing whether it is acting or not on behalf of a User.

      2) Authentication mechanisms discovery at the RS

      This HTTP OPTIONS request should also be supported by a RS. When a client first contacts a RS, it does not necessarily know the authentication
      methods that are currently supported by the RS. This means that the same request as the one used for the GS should be available for a RS as well.

      Denis

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



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


      --------------DE088F9D0F19F60E8DC96A4C-- From nobody Mon Aug 31 20:13:34 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 019E33A091F for ; Mon, 31 Aug 2020 20:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fp5EALwtl6pK for ; Mon, 31 Aug 2020 20:13:31 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDD03A0921 for ; Mon, 31 Aug 2020 20:13:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0813DP4Y014794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 23:13:27 -0400 Date: Mon, 31 Aug 2020 20:13:24 -0700 From: Benjamin Kaduk To: Denis Cc: "txauth@ietf.org" Message-ID: <20200901031324.GR16914@kduck.mit.edu> References: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [GNAP] Authentication mechanisms discovery 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, 01 Sep 2020 03:13:33 -0000 On Tue, Aug 25, 2020 at 11:37:45AM +0200, Denis wrote: > Hi Dick, > > A few arguments: > > * The 401 (Unauthorized) status code indicates that the request has > not been applied because it lacks valid authentication credentials > for the target resource. > Information about how to authenticate is NOT in the HTTP > Authorization header. So it is not a discovery mechanism but, at > best, a trial and error mechanism. I'm not sure that I'm understanding you, here. Yes, the 401 HTTP status code does not convey information about how to authenticate, but per https://tools.ietf.org/html/rfc7235#section-3.1 the WWW-Authenticate header field MUST be included in the response, and that header field does contain one or more challeng that shows how to authenticate, potentially along with parameters for each method. So are you also trying to say that the combination of HTTP 401 and WWW-Authenticate is also "not a discovery mechanism"? Thanks, Ben
      The use case is a bit complex (payment, etc.), but I think= there are 2 important items in relation to SSI :=C2=A0
      - it is interes= ting to integrate just like it is with OIDC or FIDO for instance, SSI is no= w part of the ecosystem (ex: DID Auth / SIOP is considered by openid)=C2=A0=
      - you get the ability to handle somes cases better with verified= credentials (which the example illustrates: it's better to confidently= check the age before you even issue the token).=C2=A0"On the Internet, nobody knows you're a dog" -&g= t; maybe not any more (at least if the issuer wants to keep his=C2=A0reputa= tion intact).=C2=A0
      Btw it helps for privacy too (zkp).

      Of course, one can still use GNAP or SSI separately= =C2=A0(This use case=C2=A0can be solved without=C2=A0= using an AS and a RS -> maybe but it can als= o be solved with AS and RS).

      And I don't think it changes the core design of what we= 're discussing.=C2=A0

      Fabien
      =

      On Fri, Aug 21, 2020 at 3:14 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>= ; wrote:

      On Fri, Aug 21, 2020 at 9:02 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:
      =
      The SSI trick is not the ticket =E2=80=94 the SSI portion here is &quo= t;She indicates that she is a resident of= Bamberg=E2=80=9D. We=E2=80=99d like Alice to be able to do that in a verif= iable and programatic way that we can enable in the protocol flow.
      Yes.=C2=A0
      The purpose of SSI = in this use case is to illustrate that authz flows will have many claim ori= gins. Flows will have many situations where GS relies on claims produced/pr= esented by other ASs for a compound Authz decision.=C2=A0
      Best re= gards
      /Francis

      =C2=A0=E2=80=94 Justin

      <= blockquote type=3D"cite">
      On Aug 21, 2020, at 8:48 AM, Denis <denis.ietf@free.fr>= ; wrote:

      =20

      Hello Francis,<= p class=3D"MsoNormal">This WG has not been formed to address SSI (Self sovereign identity). This use case = can be solved without us= ing an AS and a RS
      and       without using a "Self Sovereign Identity (SSI)" approach.<= span style=3D"font-family:Arial" lang=3D"EN-US">

      -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e visits the website of AC-Tickets.

      <= p class=3D"MsoNormal" style=3D"margin-left:36pt">-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Alic= e looks up and finds "Bamberg Symphony", the concert she wants to attend.

      -=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e is informed that she can get a discount price if she is a resident of Bamberg.

      -=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e fills a form and enters the requested information.
      =C2=A0She indicates that she is a resident of Bamberg and so she gets the discounted price.

      = -=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e makes the payment using 3D secure.

      -<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e gets back a QR code on her phone that will be scanned when entering the concert hall.

      -<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Alic= e goes to the concert at Bamberg Symphony.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 At t= he entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert,
      =C2=A0her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only
      =C2=A0for the residents of Bamberg.

      -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If t= he person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg,
      =C2=A0she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
      ("On the Internet, nobody knows you're a dog". Peter Steiner's carto= on, as published in The New Yorker = on July 5, 1993).

      This is simple, efficient and easy to implement right now.

      This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket .
      If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask
      the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
      that the individual is indeed over 60 but in addition the name on the       identity card or the passport will be checked against the name on the railway
      ticket and that picture matches with the face of the person in front of the train controller.

      Anyway, IMHO, I don't bel= ieve that this use case should be solved using GNAP.

      Denis

      PS. This use= case has been posted here:
      https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-p= urchasing-a-concert-ticket-without-disclosing-her-identity

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



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

      This I think makes it a very flexible model, = while 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 i= s the new diagram where=C2=A0++++ refers=C2=A0to what Endpoint/Human intera= ction and ----> refers to interaction among services.
      <= font face=3D"monospace">
      =C2= =A0 =C2=A0 +-------------+ =C2=A0 =C2=A0 =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 NOTE

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

      XAuth

      The use of GNAP in this document is not int= ended 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 wi= dely 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_Advanced]=C2=A0and JOSE Authenticatio= n=C2=A0[JOSE_Authentication]=C2=A0that = describes the JOSE mechanisms for client authentication.

      The technology landscape has changed since OAuth 2.0 was init= ially 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) th= at are widely deployed.

      GNAP simplifies the= overall architectural model, takes advantage of today's technology lan= dscape, provides support for all the widely deployed use cases, offers nume= rous 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 c= ompatible with OAuth 2.0, it strives to minimize the migration effort.

      The suggested pronunciation of GNAP is "gu= h-nap".

      1.1.=C2=A0The Grant

      Th= e Grant is at the center of the protocol between a client and a server. A G= rant Client requests a Grant from a Grant Server. The Grant Client and Gran= t Server negotiate the Grant. The Grant Server acquires authorization to gr= ant 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 m= odes 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 requ= ires from a GS for resource access. This step is not in scope for this docu= ment.

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

      (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 b= y the GS to determine access granted to the GC. This step is not in scope f= or this document.

      1.3.=C2=A0Human Interactions

      The Grant Client may be int= eracting 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 p= rotocol:

          +--------+                  =
             +------------+
    |  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. The addition of the human interactions (A) - (C) are=C2=A0= bolded=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 r= esource access

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

      (3) The GC and GS ma= y negotiate the Grant

      (B) The G= S may interact with the User for grant authorization=

      (C) The GS may interact with the RO for gra= nt 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 co= uld be a legal entity that has a software component that the Grant Server i= nteracts with for Grant authorization. This interaction is not in scope of = this document.

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

      • Clie= nt Owner=C2=A0(CO) - the legal entity that owns the Grant Client.<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.4-2.1" style=3D"text-decoration-line:none;color:rgb(102,102,102)" tar= get=3D"_blank">
      • Grant Server Owner=C2=A0(= GSO) - the legal entity that owns the Grant Server.
      • Claims Issuer=C2=A0(Issuer) - a legal entity tha= t issues identity claims about the User. The Grant Server Owner may be an I= ssuer, 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 m= aking a grant to the CO

        (B) User trusts= the CO to act in the User's best interest with the Grant the GSO grant= s 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 man= age access to the RO resources

        1.5.=C2=A0Ter= minology

        Roles

        • Grant Client=C2=A0(GC)

          • may want access to resources at a Resource Serve= r
          • may be interacting with a User a= nd want identity claims about the User
          • requests the Grant Service to grant resource access and identity cla= ims

        • Grant Server=C2=A0(GS)

          • accepts Grant requests from the GC for resource access = and identity claims
          • negotiates th= e 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 a= nd identity claims to the GC

        • Re= source 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 d= ocument
          • verifies the GS granted ac= cess 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).
            • <= li id=3D"gmail-m_-6821299627238716443gmail-m_-6222960488018950372m_-6756247= 088188955098gmail-m_8789399216572105611gmail-m_3993451923099602247gmail-m_-= 3253219048718590634gmail-m_-7491335305061859892gmail-m_-5602902245930246723= gmail-m_-8634122456003472927gmail-section-1.5-4.2.2.2" style=3D"margin:0px = 0px 0.25em">has delegated resource access management to the GS.
          • may be the User, or may be a different enti= ty that the GS interacts with independently.

          Reused Terms

          • acce= ss token=C2=A0- an access token as defined in=C2=A0[R= FC6749]=C2=A0Section 1.4.. An GC uses an access token for resour= ce access at a RS.
          • Claim= =C2=A0- a Claim 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 C= lient as defined in=C2=A0[RFC6749]=C2=A0Section 2.2.=
          • ID Token=C2=A0- an ID T= oken as defined in=C2=A0[OIDC]=C2=A0Section 2. ID Token= s are issued by the GS. The GC uses an ID Token to authenticate the User.
          • NumericDate=C2=A0- a Numer= icDate as defined in=C2=A0[RFC7519]=C2=A0Section 2.<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.5-6.5" style=3D"text-decoration-line:none;color:rgb(102,102,102)" tar= get=3D"_blank">
          • authN=C2=A0- short for authentication.
          • authZ=C2=A0- short for authorization.

          New Terms

          • GS URI=C2=A0- the endpoint at the GS the GC calls to create = a Grant, and is the unique identifier for the GS.
            • <= li id=3D"gmail-m_-6821299627238716443gmail-m_-6222960488018950372m_-6756247= 088188955098gmail-m_8789399216572105611gmail-m_3993451923099602247gmail-m_-= 3253219048718590634gmail-m_-7491335305061859892gmail-m_-5602902245930246723= gmail-m_-8634122456003472927gmail-section-1.5-8.2" style=3D"margin:0px 0px = 0.25em">Registered Client=C2=A0- a GC that has registered = with the GS and has a Client ID to identify itself, and can prove it posses= ses a key that is linked to the Client ID. The GS may have different polici= es for what different Registered Clients can request. A Registered Client M= AY be interacting with a User.
          • Dynamic Client=C2=A0- a GC= that has not been previously registered with the GS, and each instance wil= l generate it's own asymetric key pair so it can prove it is the same i= nstance of the GC on subsequent requests.. The GS MAY return a Dynamic Clie= nt a Client Handle for the Dynamic Client to identify itself in subsequent = requests. A single-page application with no active server component is an e= xample 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 dire= cts the User to interact with the GS. This document defines the interaction= modes: "redirect", "indirect", and "user_code&quo= t; in=C2=A0Section 5.
          • = Grant=C2=A0- the user identity claims and/or resource acce= ss the GS has granted to the Client. The GS MAY invalidate a Grant at any t= ime.
          • Grant URI=C2=A0- the= URI that represents the Grant. The Grant URI MUST start with the GS URI.
          • Access=C2=A0- the access = granted by the RO to the GC and contains an access token. The GS may invali= date 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 us= ed 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


      --
      Francis Pouatcha
      Co-Founder and Technical Lead=
      adorsys GmbH & Co. KG
      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      FI : problem is that if you show that, most peo= ple will assume it's mandatory (as least for the alt2 part). At least I= think that's what most readers would assume from reading the schema.


      Are we sure we need to fo= rmally separate B and C? This goes beyond previous discussions of separatin= g the front and back channels, and I don't really see the advantage (ma= ybe there is: which use cases would be impossible to do otherwise?).=C2=A0<= /div>
      We have a situation where RP =3D!=3D RC. And e= ach of them have their own AS.

      FI : see discussion at the start of the message=C2=A0

      <= div dir=3D"ltr">

      So overall, I think Alt2 over-complexif= ies the situation. We need to remain flexible.
      Why not simply hav= e an (optional) way of separating these flows from the GS?=C2=A0
      With GNAP, we are at an abstraction=C2=A0level-0, like r= eferred=C2=A0to in my former post. At level-1 we can address concrete proto= cols like oAuth, OIDC, [SSI/DiD/VC] and the diagram will look simple.
      =

      FI : yes.=C2=A0=C2=A0


      For instance, an (optional) Int= eract Server (IS) could provide support for a decoupled front-channel:=C2= =A0
      - it does not change the interaction between a GC and a GS. I= t 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 o= wn, for instance). In case nothing is specified, the GS decides.=C2=A0
      - the IS is able to handle the front-channel for idclaims and consent= , and return back to the GS what access tokens are required.
      - no= tice that although the IS is focused on front-channel interaction, there ar= e 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 th= e end-user is not the one that is asked for consent / then of course, if th= e RC logs in, he would be able to manage his consent policies).=C2=A0
      =
      What you mention here is why I display RP-AS and 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 where y= our front-channel is located (GC, GS, third-party).
      Yes. I agree with=C2=A0you. How can we make this=C2=A0 visible in a d= iagram?

      FI : let me think= about it ;-)
      =C2=A0

      This I t= hink makes it a very flexible model, while enabling what we're after.= =C2=A0
      Yes.
      /Francis=C2=A0

      Fabien=C2=A0


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

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

      <= /div>
      =C2=A0 =C2=A0 +-------------+ =C2=A0 =C2= =A0 =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=A0Reso= urce =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|
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 += =C2=A0 +--->| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 +-->| =C2=A0= =C2=A0 =C2=A0 =C2=A0|
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0|=C2=A0 =C2= =A0 +--------+ =C2=A0 =C2=A0 | =C2=A0 +--------+
      =C2=A0 =C2=A0 =C2=A0 = =C2=A0 + =C2=A0|=C2=A0 =C2=A0 =C2=A0 =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=A0Resource =C2=A0|
      =C2=A0 =C2=A0 | C= lient | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 i= s part of the protocol:
      Alt-1: on= ly (1..6). This is what you specified in section 1.2, and I am fine with th= at.
      Alt-2: Alt-1=C2=A0+=C2=A0(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. A= s in many cases, like in oAuth [RP-AS] could be the same entity like [GS].<= /font>

      Best regards.
      /Francis


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

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

      In the abstract diagram in 1.3, I show the interactions between the U= ser and the GC, the User and the GS, and the RO and the GS. These are NOT i= nteractions that can be technically specified. The User and RO are not role= s in the protocol, but are entities in the trust model.

      I debated keeping the interactions abstract and not stating=C2=A0&quo= t;what" happened in each interaction, but thought that might be confus= ing at this stage or our discussions.

      Since it is = just an interaction between human and software, we can have the User authen= ticate to the GC as well as authorize (provide consent), and have no intera= ction 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 s= tay the same. The trust model does change though.

      = /Dick







      On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha = <fpo@adorsys.de&= gt; wrote:
      Hello Dick,=C2=A0my feedback below:

      1.2: Excellent and Focussed
      -> The word "Gr= ant Client" looks great for me.

      1.3:
      Title: Human Interactio= n -> End User Interaction
      I would title this "End User" int= eraction 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 discussio= ns there was a consensus on using "Resource Controller" instead.<= br>
      (B) I which the GS never interacts with the "Requesting Party&q= uot; 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 author= isation decision. In this case, the GS can instruct the GC to obtain those = claims. In some cases, claims on the "Requesting Party" will be o= btained 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 &quo= t;from" End Users. End users are in this case the Requesting Party, an= d the Resource Controller).

      The result can look like the modified di= agram below. With this we can address some privacy concerns 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| Cont= roller (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|
      =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 +------------+

      (B0, B1) replace (= B). Occur inside step (3), GS asks GC to collect the claims. GC contacts RP= -AS to negotiate those=C2=A0claims. But it is important to mention that tho= se Claims-RP are not the target Grant being negotiated for the resource acc= ess. They are generally=C2=A0used by GS (and later RS) as input into perfor= ming authz decisions.

      =
      (C0, C1) replace (C). They occur=C2=A0a= fter step (3) (Beware of the difference=C2=A0to Bs that occur=C2=A0inside 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"= ;.=C2=A0

      Off-topic: The split= ting of GS and AS was suggested in some discussions on the mailing list. Bu= t 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 tr= ust 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 ha= ve a structure for this section.


      1.5
      I suggest again we repla= ce Human with "End User" and still make them roles. This is:
      T= erminology (Are all roles)
      =C2=A0 -> These roles can be borne by End = Users
      =C2=A0 =C2=A0 =C2=A0-> Requesting Party (RP)
      =C2=A0 =C2=A0 = =C2=A0-> Resource Controller (RC)
      =C2=A0 -> These role can be born= e 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 face=3D"monospace">Best regards
      /Francis

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

      I just pushed an updated vers= ion of XAuth:


      Highlights:
      • renamed Client -> Grant Client
      • Introdu= ced Client Owner, Grant Server Owner as new entities
      • renamed=C2=A0A= uthorizations -> Access
      • An Access contains=C2=A0an array of RAR = objects now
      • Reworked diagram an intro to focus on Grant, and separa= te protocol roles from human interactions.
      New introduction i= ncluded below for your convenience

      /Dick
      <= ul style=3D"padding:0px;margin:0px 0.5em 1em 0px;list-style:none;line-heigh= t:normal">

    • 1.=C2= =A0Introduction

      EDITOR NOTE

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

      <= p id=3D"gmail-m_-6222960488018950372m_-6756247088188955098gmail-m_878939921= 6572105611gmail-m_3993451923099602247gmail-m_-3253219048718590634gmail-m_-7= 491335305061859892gmail-m_-5602902245930246723gmail-m_-8634122456003472927g= mail-section-1-3" style=3D"padding:0px;margin:0px 0px 1em">XAuth

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

      This docu= ment 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[RFC67= 50], OpenID Connect=C2=A0[OIDC]=C2=A0- an ex= tension of OAuth 2.0, as well as other extensions. Related documents includ= e: GNAP - Advanced Features=C2=A0[GNAP_Advanced]=C2=A0and JOSE Authentication=C2=A0[JOSE_Authent= ication]=C2=A0that describes the JOSE mechanisms for client auth= entication.

      The technology landscape has changed since OAuth 2.0 was in= itially drafted. More interactions happen on mobile devices than PCs. Moder= n 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 mod= el, takes advantage of today's technology landscape, provides support f= or all the widely deployed use cases, offers numerous extension points, and= addresses many of the security issues in OAuth 2.0 by passing parameters s= ecurely between parties rather than via a browser redirection.<= /a>

      While GN= AP is not backwards compatible with OAuth 2.0, it strives to minimize the m= igration effort.

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

      1.1.=C2=A0The Grant

      The Grant is at th= e center of the protocol between a client and a server. A Grant Client requ= ests a Grant from a Grant Server. The Grant Client and Grant Server negotia= te 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 Cli= ent.

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

      1.2.=C2=A0Protocol Roles

      There a= re three roles in GNAP: the Grant Client (GC), the Grant Server (GS), and t= he 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.

      <= p id=3D"gmail-m_-6222960488018950372m_-6756247088188955098gmail-m_878939921= 6572105611gmail-m_3993451923099602247gmail-m_-3253219048718590634gmail-m_-7= 491335305061859892gmail-m_-5602902245930246723gmail-m_-8634122456003472927g= mail-section-1.2-4" style=3D"padding:0px;margin:0px 0px 1em">(2) The GC mak= es 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 retu= rns a Grant to the GC (Grant Response=C2=A0Section 4.1).

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

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

      =

      1.3.=C2=A0Human Interactions

      The Grant Client may be interacting with a human end-us= er (User), and the Grant Client may need to get authorization to release th= e Grant from the User, or from the owner of the resources at the Resource S= erver, 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. The addition of the= human interactions (A) - (C) are=C2=A0bolded=C2=A0below.<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.3-4" style=3D"text-decoration-line:none;color:rgb(102,102,102)" targe= t=3D"_blank">

      (A) The User is interacting with a GC, and the GC needs res= ource 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 a= ccess

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

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

      (B) The GS may interact w= ith the User for grant authorization

      (C) The GS m= ay interact with the RO for grant authorization

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

      (5) The GC accesses resources at th= e RS

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

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

      1.4.=C2=A0Tru= st Model

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

      These three entities do not inte= ract 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 t= rusts 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 G= SO

      (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 Us= er
        • requests the Grant Service to grant resource access and ide= ntity 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 authoriza= tion from the User before granting identity claims to the GC
        • a= cquires 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
      =

      Human= s

      • User=

        • the person interacting with the Grant Clien= t.
        • 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).
        • <= /a>
        • may be= the User, or may be a different entity that the GS interacts with independ= ently.

      Reused Terms

      • access token= =C2=A0- an access 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 Claim as defined in=C2=A0[OI= DC]=C2=A0Section 5. Claims are issued by a Claims Issuer.
      • 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. Th= e GC uses an ID Token to authenticate the User.
        • NumericDate=C2=A0- a NumericDate as defined in=C2=A0[RFC7519]=C2=A0Section 2.
      • authN=C2=A0- short for authentication.
        • <= li id=3D"gmail-m_-6222960488018950372m_-6756247088188955098gmail-m_87893992= 16572105611gmail-m_3993451923099602247gmail-m_-3253219048718590634gmail-m_-= 7491335305061859892gmail-m_-5602902245930246723gmail-m_-8634122456003472927= gmail-section-1.5-6.7" style=3D"margin:0px 0px 0.25em">authZ=C2=A0- short for authorization.

      New Terms

        GS URI=C2=A0- the 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 i= tself, and can prove it possesses a key that is linked to the Client ID. Th= e 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 w= ill 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 Cl= ient a Client Handle for the Dynamic Client to identify itself in subsequen= t 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 th= e GS has granted to the Client. The GS MAY invalidate a Grant at any time.<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.5-8.6" style=3D"text-decoration-line:none;color:rgb(102,102,102)" tar= get=3D"_blank">
      • Grant URI=C2=A0- the URI that represents the Grant. T= he Grant URI MUST start with the GS URI.
      • Access=C2= =A0- the access granted by the RO to the GC and contains an access token. T= he 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 refre= sh 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


      --
      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
      Hello

      I just pushed an updated vers= ion of XAuth:


      Highlights:
    • renamed Client -> Grant Client
    • Introduced Client Owner, Gr= ant 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 fr= om human interactions.
      • New introduction included below for yo= ur 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 do= cument as:

      XAuth

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

      = This document describes the core Grant Negotiation and Authorization Protoc= ol (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<= span style=3D"">[OIDC]=C2=A0- an extension of OAuth 2.0, a= s well as other extensions. Related documents include: GNAP - Advanced Feat= ures=C2=A0[GNAP_Advanced]=C2=A0a= nd JOSE Authentication=C2=A0[JOSE_Aut= hentication]=C2=A0that describes the JOSE mechanisms for client = authentication.

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

      GNAP simpl= ifies the overall architectural model, takes advantage of today's techn= ology landscape, provides support for all the widely deployed use cases, of= fers numerous extension points, and addresses many of the security issues i= n OAuth 2.0 by passing parameters securely between parties rather than via = a browser redirection.

      While GNAP is not backwards compa= tible 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 t= he center of the protocol between a client and a server. A Grant Client req= uests a Grant from a Grant Server. The Grant Client and Grant Server negoti= ate the Grant. The Grant Server acquires authorization to grant the Grant t= o the Grant Client. The Grant Server then returns the Grant to the Grant Cl= ient.

      The Grant Request may contain information abou= t the User, the Grant Client, the interaction modes supported by the Grant = Client, the requested identity claims, and the requested resource access. E= xtensions may define additional information to be included in the Grant Req= uest.

      1.2.=C2=A0P= rotocol 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 in= teract:

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

      (1) The GC may query the RS to determine what the RS requires from a G= S 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].<= /p>

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

      (4) The G= S returns a Grant to the GC (Grant Response=C2=A0Section 4.1= ).

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

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

      1.3.=C2=A0= Human Interactions

      The Gr= ant Client may be interacting with a human end-user (User), and the Grant C= lient 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
      <= /a>

      Steps (1) - (6) are the same as=C2=A0Section 1.2. T= he addition of the human interactions (A) - (C) are=C2=A0bolded=C2=A0below.

      (A) The User is interactin= g with a GC, and the GC needs resource access and/or identity claims (a Gra= nt)

      (1) The GC may query the RS to determin= e 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 G= S may interact with the User for grant authorization

      (C) The GS may interact with the RO for grant authorizat= ion

      (4) The GS returns a Grant to the GC<= a href=3D"https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#sect= ion-1.3-11" class=3D"gmail-pilcrow" style=3D"text-decoration-line:none;colo= r:rgb(102,102,102)">

      (5) The GC accesses resources at the RS

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

      Alternatively, the Resourc= e Owner could be a legal entity that has a software component that the Gran= t 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 l= egal entity that owns the Grant Client.
      • Grant Server Owner=C2=A0(GSO) - the legal entity t= hat owns the Grant Server.
      • Claims Issuer=C2=A0(Issuer) - a legal entity that issues identi= ty claims about the User. The Grant Server Owner may be an Issuer, and the = Resource Owner may be an Issuer.

      These thr= ee entities do not interact in the protocol, but are trusted by the User an= d 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>

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

      (B) User trusts the CO to act in the Us= er'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 th= e 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 w= ant identity claims about the User
        • requests the Grant Service to grant resource access and identity= claims

      • Gr= ant Server=C2=A0(GS)

      • Resource Server=C2=A0(RS)=

        • has resour= ces 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

      <= ul class=3D"gmail-normal" style=3D"padding:0px;margin:0px 0px 1em 2em">

    • User

      • the person interacting with= the Grant Client.
      • has d= elegated 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 resou= rces at the Resource Server (RS).
      • has delegated resource access management to the GS.
      • may be the User, or may be a differen= t entity that the GS interacts with independently.

      • Reused Terms

      N= ew Terms

      • GS URI=C2=A0- the endpoint at the GS the GC calls to create a Grant, and is th= e unique identifier for the GS.
      • Registered Client=C2=A0- a GC that has registered with th= e GS and has a Client ID to identify itself, and can prove it possesses a k= ey 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 i= nteracting 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 pa= ir 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=C2=A0- a uniqu= e 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 inte= ract with the GS. This document defines the interaction modes: "redire= ct", "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 UR= I.
      • Access=C2=A0= - 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=C2=A0- the URI that represents the Acc= ess 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.
      <= /div>


      --000000000000da831005acf28af3-- From nobody Sun Aug 16 00:12:33 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 0EACB3A081F for ; Sun, 16 Aug 2020 00:12:32 -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_FACE_BAD=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 wlY_ocXGxWla for ; Sun, 16 Aug 2020 00:12:28 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 7874C3A0820 for ; Sun, 16 Aug 2020 00:12:28 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id h4so14633958ioe.5 for ; Sun, 16 Aug 2020 00:12:28 -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=JIyB0JAyZ63f2Ojk0XiR2y3w8kjmKU4C5bUgD21jPcs=; b=uPMxH7cp5LcBb7M7o/WN3rWrHZgPDczQ4kCN9PwIMEOV8AMLGY1PJZXoaJKR1wyeUr xl1nx75ntZe2ydZOMHnCL/r6zMyg271gE9MabJ6Lc+eD65dalnFjY7N9R55GJ3sVwNrp fZHv6yB9sFWhqEwkh8HrpGsHSqvaPiM2c/eqwyKHrEcYp5WKkJGYE0dyD10XkjppjlQ6 0C6bWdC9EZrGNNNn0pottJh2X5iDummwejCT5rJxkG3dpup9lXaOiRSjDY8iyE9lbiei fjoZLYvCgKz5cor0EXwlgaIvmKauky0eukGT/Oy3NQM5t5IC7Vc02CU/UL0oku9XwP73 zLkA== 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=JIyB0JAyZ63f2Ojk0XiR2y3w8kjmKU4C5bUgD21jPcs=; b=XkZIyJrWVx2wlRNakgl3usUy4B4xNwawStpZ0u2Q+AlU3WRmxgvY/dtFQL4YjfPsZq sbBCuF9vLp/uuplF5BDeWTryvriMkiMa5lG9tuc+pjHe7w3mTgKhS+c2Yaron91L/Ofa +Puk9aODn4LA7JAhNOHigjP1hKFpAzjiib54YzKI20huL+JdKHT7e5OVmrY2MtTslvQP +9b+p+SJsMvOv33Syc/h73cIEbp6u8pfH0SA8RKjEsc7PgH//f53O2EGv2u1kmjpHMEi I1e6gncSm1COT8csJ+/aYHzm7lyFnIweds5srD1c6e3g7QaAXdEE1KwLgTiCgj9ipXTp WrgA== X-Gm-Message-State: AOAM530eLA0Gh4nixc2m1sEwIkfG8S4Hq1Qx878o9rHyz23PGqaHDkJH cG8/YafbWUpDPLxNQ/84kp9sZxUYdtXj6v4SXXE= X-Google-Smtp-Source: ABdhPJyOoMDUaxk53cesVrZHFPSvmHg8q4hkKyc4ZpxlJmgDKJ8MJButoGgxAbxYRTXCVQteBjRjrBbx0d4YUpzXGhg= X-Received: by 2002:a05:6638:22c7:: with SMTP id j7mr9541742jat.77.1597561947482; Sun, 16 Aug 2020 00:12:27 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> In-Reply-To: From: Fabien Imbault Date: Sun, 16 Aug 2020 09:12:16 +0200 Message-ID: To: Denis Cc: Francis Pouatcha , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000062f00305acf96025" Archived-At: Subject: Re: [GNAP] Terminology - into Github Issues 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: Sun, 16 Aug 2020 07:12:32 -0000 --00000000000062f00305acf96025 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 on creating a durable resource for this. As with the core spec, doesn't mean we can't discuss on the mailing list. Fabien Le ven. 14 ao=C3=BBt 2020 =C3=A0 17:33, Denis a =C3=A9= crit : > Hello Francis, > > - 1. > > The mailing list is the usual way to exchange short information. The use > of the wiki should be restricted to long contributions. > You are invited to contribute on the mailing list by proposing both a > wording and its meaning if a current proposed wording > does not meet your expectations and whenever possible with a short > rational. > > Denis > > We have been having a lot of great suggestions and discussion in the list > on terms. As we go on, a lot of knowledge gets buried in the mailing > archives. This why i suggest we use the use cases github wiki to: > > - start compiling discussions on single terms into issues (tickets), > - also create a ticket for each use case, either linking the wiki page, > > The wiki page will be used to hold the last consolidated state of the > definition or use case. > > Using tickets to complement wiki pages will allow us to: > - move valuable contributions on each word or use case to the comment > section of the corresponding ticket. > - allow contributors or visitors to read the summary of what was discusse= d > on a term (resp. use case) before proceeding with additional > comments/questions. > - Help focus toward reusable content. > > What do you think? > > Best regards > /Francis > > On Fri, Aug 14, 2020 at 10:30 AM Justin Richer wrote: > >> +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps =E2= =80=9C operator=E2=80=9D as >> the role they play when, you know, operating the . (Where >> should still have a more specific name.) >> >> =E2=80=94 Justin >> >> On Aug 14, 2020, at 8:23 AM, Fabien Imbault >> wrote: >> >> Hi Denis, >> >> Thanks for your feedback. >> Comments inline (marked with FI). >> >> Fabien >> >> On Fri, Aug 14, 2020 at 12:02 PM Denis wrote: >> >>> Hi Fabien, >>> >>> Thank you for your inputs, a ball is finally rolling. >>> >>> An attempt. >>> >>> I would add upfront: User =3D human person >>> >>> FI : then end-user is clearer if you want to indicate specifically a >> human user. One can also create system users. >> >>> * =3D application that requests access to Resource Servers (RS) >>> through a Grant Server (GS). * >>> Examples: a web server, a browser-based app, a mobile app, an IoT devic= e. >>> >>> A few explanations: "through" does not sound appropriate since it could >>> be interpreted as the GS being necessarilly placed between the Client a= nd >>> the RS. >>> In addition, more than one GS may >>> be necessary. >>> >>> My proposal: * =3D application that requests access to Resourc= e >>> Servers (RS) **on behalf of a User by using one or more Grant Servers >>> (GS) * >>> *Examples: a web server, a browser-based app, a mobile app.* >>> >>> FI: agreed. >> >>> >>> *GS =3D computing service that manages the grant lifecycle to a >>> on behalf of a Resource Controler (RC).* >>> Note : for privacy reasons, the GS may be issuing grants without >>> knowledge of which resources are requested. >>> >>> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be >>> fully ignorant of the existence of the RSs and hence of the RCs. >>> In addition, "*grant life cycle*" is undefined. >>> >>> My proposal: *GS =3D server issuing access tokens to a Client after >>> successfully authenticating the User* >>> >>> >>> *Note 1: for privacy reasons, the GS may be issuing access tokens >>> without the knowledge of which resources are requested. Note 2: a GS is >>> able to disclose to a User the User attributes that it manages. * >>> >>> FI: I find the new definition less clear. It's not because you don't >> know which RS is called that we shouldn't say the decision is made by th= e >> RC. >> "grant life cycle" is indeed currently undefined, what i had in mind is >> basically the grant flow from the GNAP protocol, possibly also including >> revocation etc. >> Not sure why Note 2 is important to put here. >> >> >>> *RS =3D computing service that grants access only if its Resource >>> Controler (RC) consents.* >>> Note : the consent may involve a human interaction or may be automated >>> based on access control policies. >>> >>> I dislike "*its Resource Controler (RC) consents" *because it may let >>> think that a human person always needs to consent. >>> >>> My proposal: *R* >>> *S =3D server hosting protected resources, capable of accepting and >>> responding to protected resource requests >>> when access tokens are being used* >>> >>> FI : that is why I suggested a note to make sure it is correctly >> understood. I'm not sure the proposed alternative is clearer. >> >>> >>> *RC =3D entity which is controlling the access to a protected resource.= * >>> Note : a RC may be manually operated by a human or delegated to a >>> machine, partially or completely. >>> >>> A RC is not an entity but a function. I would also place the machine >>> case first. >>> >>> My proposal: >>> *RC =3D function tightly coupled with a RS which controls the accesses = to >>> a protected resource * Note : the function may >>> be operated either by a machine or by a human person or by some combina= tion >>> of both. >>> >>> FI : your proposition on the note makes it much better. On the main >> definition, I'm not sure what you mean by function, as a result I'm not >> sure a reader would understand. Why do you need to say "tightly coupled?= " >> >>> *Consent =3D the process of asking a RC to accept or decline based on a >>> grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D= or =E2=80=9Cno=E2=80=9D consent >>> decision.* >>> >>> I would instead speak of the "User Consent". The User Consent is a set >>> of choices among a proposed set of choices. It is not simply a "yes" or >>> "no" consent decision. >>> >>> My proposal: *User Consent =3D ability for a User, after being informed= , >>> of choosing to release or not to a RS some attributes contained in one = or >>> more access tokens* >>> >>> >> FI: this may be misleading I think. The consent is done by a RC (or in >> OAuth terms, RO), not the application user. >> I agree there may be a combination of consent decisions, but I think it'= s >> important to say that in the end for each individual choice, you do have= a >> yes/no decision. >> >>> >>> Denis >>> >>> >>> Fabien >>> >>> On Thu, Aug 13, 2020 at 3:55 PM Denis wrote: >>> >>>> Fabien, >>>> >>>> IMHO, nothing is wrong with keeping "Client" since it has a wide sprea= d >>>> usage >>>> ... but only as long as we can agree on a short and a clear definition >>>> for it. >>>> >>>> I can provide the beginning of such a definition: " application ..." >>>> >>>> If someone could go a little bit further, this would help. :-) >>>> >>>> A similar argumentation for GS. It could be used but only as long as >>>> we can agree on a short and a clear definition for it. >>>> Any proposal ? >>>> >>>> Denis >>>> >>>> Hi, >>>> >>>> Nothing inherently wrong with Client/AS, which has worked for years in >>>> the context of OAuth2. The question is to know whether we can build th= e new >>>> protocol with the same concepts and deal with their known limitations,= or >>>> if we're better off with more adapted concepts less prone to >>>> misunderstandings. >>>> >>>> Verb vs Noun: >>>> Problem is that the grant (noun) can only be understood if there is a >>>> grant(verb), i.e. some action that grants something. >>>> The grant (noun) definition directly derives from the verb : "somethin= g >>>> granted ..." >>>> >>>> I personally have no issue even with the fairly convoluted "The Grant >>>> Server issues a grant to the Grant Client representing access that has= been >>>> granted" (except perhaps from the word Client, but that's a different >>>> issue). >>>> By the way, grant is nothing new, it's used extensively in OAuth2 as >>>> "grant types" (whatever that means). >>>> >>>> Dick summarized well the reasons why he uses GS instead of AS : >>>> 1) "grant" is in the working group name (a weaker reason, but still ha= s >>>> been approved). Question: would our reasoning if the protocol ended up >>>> being called OAuth3? >>>> 2) grant =3D larger in scope than AS (not only authorization), as it a= t >>>> least includes idclaims + other use cases like payment (?) - no consen= sus, >>>> see difference in appreciation between Justin and Dick >>>> >>>> As for "Client", if most people think it is problematic, it seems a >>>> good reason to change if we find a better alternative. >>>> Quoting Dick again: "The confusion in my experience usually stems from >>>> people working with software that is acting in multiple roles. IE, the >>>> software that is acting as a client in once context, is also acting as >>>> an RS in other contexts, or even acting as an AS. The other confusion = is >>>> that people view clients as being the software the user is using -- >>>> although it may not be acting as a client in the oauth context." and >>>> later "I do agree that it is not the best term in GNAP. Primarily beca= use >>>> GNAP is a combination of the client from OAuth 2, and the relying >>>> party from OIDC." >>>> >>>> So far there's no consensus however, recent tries: Initiating >>>> Application (Denis), Orchestrator (Francis). >>>> >>>> Cheers >>>> Fabien >>>> >>>> >>>> >>>> >>>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >>>> wrote: >>>> >>>>> I would be against using "grant" as both a verb and a noun and stick >>>>> purely with one or the other. (In the charter the only use of "grant"= is in >>>>> the verb: "granted"). >>>>> >>>>> Using it as both a verb and a noun will be confusing and less >>>>> accessible. >>>>> >>>>> I think it will be confusing to say "The Grant Server issues a grant >>>>> to the Grant Client representing access that has been granted" >>>>> >>>>> Whether the access takes place via a token being returned and used at >>>>> a resource server, or "claims" that are directly returned from the "G= rant >>>>> Server" I think should be largely irrelevant when it comes to the nam= ing of >>>>> the roles. >>>>> >>>>> In almost all use cases that I have seen the "Grant Server" is making >>>>> a policy based decision "to grant" access to requested resource(s). T= o me, >>>>> that is the fundamental operation happening. I think nearly all use c= ases >>>>> can be applied to that, e.g. the GS grants access to >>>>> - identity attributes for the end user >>>>> - verify an identity attribute (e.g. that user is over 18) >>>>> - all users photos at resource server X >>>>> - a single photo with id 12345 at resource server Y >>>>> - resource of type X at any resource server that trusts the Grant >>>>> Server >>>>> - call a payment API with specific properties (e.g. amount < 5) >>>>> - call a file storage API >>>>> - call a "contract signing" API with specific properties (e.g. >>>>> contract hash of xxx,) >>>>> >>>>> While "client" is problematic, it does now have wide spread usage, so >>>>> perhaps we are stuck with it. >>>>> However I agree with Justin and think "Grant Client" makes things mor= e >>>>> confusing. >>>>> >>>>> What is wrong with keeping "Client" and "Authorization Server"? >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at >>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772. >>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise= , Regus >>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>>> >>> -- >>> 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/ > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000062f00305acf96025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      +1 on creating a dura= ble resource for this.=C2=A0

      As with the core spec, doesn't mean we can't discuss on the ma= iling list.=C2=A0

      Fabien=

      Le ven. 14 ao=C3=BBt 2020 =C3=A0 17:33, Denis <denis.ietf@free.fr<= /a>> a =C3=A9crit=C2=A0:
      =20 =20 =20
      Hello Francis,

      - 1.

      The mailing list is the usual way to exchange short information. The use of the wiki should be restricted to long contributions.
      You are invited to contribute on the mailing list by proposing both a wording and its meaning if a current proposed wording
      does not meet your expectations and whenever possible with a short rational.

      Denis

      =20
      We have been having a lot of great suggestions and discussion in the list on terms. As we go on, a lot of knowledge gets buried=C2=A0in the mailing archives. This why i suggest we use the use cases github wiki to:

      - start compiling discussions on single terms into issues (tickets),
      - also create a ticket for each use case, either linking the wiki page,

      The wiki page will be used to hold the last consolidated=C2=A0state of the definition or use case.

      Using tickets to complement wiki pages will allow us to:
      - move valuable contributions on each word or use case to the comment section of the corresponding ticket.
      - allow contributors or visitors to read the summary=C2=A0of what was discussed on a term (resp. use case) before proceeding with additional comments/questions.
      - Help focus=C2=A0toward reusable content.

      What do you=C2=A0think?

      Best regards
      /Francis

      On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <jricher@mit.edu> wrot= e:
      +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps =E2=80=9C<client> operato= r=E2=80=9D as the role they play when, you know, operating the <client>. (Where <client> should still have a more specific name.)

      =C2=A0=E2=80=94 Justin

      On Aug 14, 2020, at 8:23 AM, Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:

      Hi Denis,=C2=A0

      Thanks for your feedback.=C2=A0
      Comments inline (marked with FI).

      Fabien

      On Fri, Aug 14, 2020 at 12:02 PM Denis <denis= .ietf@free.fr> wrote:
      Hi Fabien,

      Thank you for your inputs, a ball is finally rolling.

      An attempt.
      I would add upfront: User =3D=C2= =A0 human person
      FI : then end-user is clearer if you want to indicate specifically a human user. One can also create system users.
      <Client> =3D application that requests access to Resource Servers (RS) through a Grant Server (GS).=C2=A0=C2=A0
      Examples: a=C2=A0web server, a browser-based app, a mobile app, an IoT device.

      A few explanations: "through" = does not sound appropriate since it could be interpreted as the GS being necessarilly placed between the Client and the RS.=C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition, more than one GS may be necessary.

      My proposal:=C2=A0=C2=A0= <Client> =3D application that requests access to Resource Servers (RS)=C2=A0on behalf of a=C2=A0User=C2=A0by using one or more Grant Servers (GS)=C2=A0
      Examples: a=C2=A0web server, a browser-based app, a mobile app.

      FI: agreed.=C2=A0=C2=A0

      GS =3D computing service that manages the grant lifecycle=C2=A0to= a <Client> on behalf of a Resource Controler (RC).
      Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested.

      I dislike "on behalf of a Resour= ce Controler (RC)". The GS may be fully ignorant of the existence of the RSs and hence of the RCs.
      In addition, "grant life cycle" is undefined.

      My proposal:=C2=A0=C2=A0= GS =3D=C2=A0server issuing access tokens to a Client after successfully authenticating the User
      Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested.
      Note 2: a GS is able to disclose to a User the User attributes that it manages.=C2=A0=C2=A0

      FI: I find the new definition less clear. It's not because you don't know which R= S is called that we shouldn't say the decision i= s made by the RC.=C2=A0
      "grant life cycle" is indeed curre= ntly undefined, what i had in mind is basically the grant flow from the GNAP protocol, possibly also including revocation etc.
      Not sure why Note 2 is important to put here.
      =C2=A0
      RS =3D computing service that grants access only if its Resource Controler (RC) consents.
      Note : the consent may involve a human interaction or may be automated based on access control policies.
      I dislike "its Resource Controler (RC) consents"=C2=A0= because it may let think that a human person always needs to consent.

      My proposal:=C2=A0RS= =3D server hosting protected resources, capable of accepting and responding to protected resource requests=C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 when access tokens are being used
      FI : that is why I suggested a note to make sure it is correctly understood. I'm not sure the proposed alternative is clearer.=C2=A0

      RC =3D entity which is controlling the access to a protected resource.=C2=A0
      Note : a RC may be manually operated by a human or delegated to a machine, partially or completely.

      A RC is not an entity but a function. I would also place the machine case first.

      My proposal:=C2=A0RC =3D function tightly coupled with a RS which controls the accesses to a protected resource
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Note : the function may be operated either by a machine or by a human person or by some combination of both.

      FI : your proposition on the note makes it much better. On the main definition, I'm not sure what you mean by function, as a result I'm not sure a reader would understand. Why do you need to say "tightl= y coupled?"=C2=A0
      Consent =3D the process of asking a RC to accept or decline based on a grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D or = =E2=80=9Cno=E2=80=9D consent decision.

      I would instead speak of the "User Consent". The User Consent is a set = of choices among a proposed set of choices. It is not simply a "yes&quo= t; or "no" consent decision.

      My proposal:=C2=A0User Consent =3D ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens


      FI: this may be misleading I think. The consent is done by a RC (or in OAuth terms, RO), not the application user.=C2=A0
      I agree there may be a combination of consent decisions, but I think it's important to say that in the end for each individual choice, you do have a yes/no decision.=C2=A0


      Denis


      Fabien

      On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@free.fr&g= t; wrote:
      Fabien,

      IMHO, nothing is wrong with keeping "Client" sinc= e it has a wide spread usage
      ... but only as long as we can agree on a short and a clear definition for it.      =

      I can provide the beginning of such a definition: " application ..."

      If someone could go a little bit further, this would help. :-)

      A similar argumentation for GS.=C2=A0 It could be used but<= span>=C2=A0only as = long as we can agree on a short and a clear definition for it.
      Any proposal ?

      Denis

      Hi,

      Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we'r= e better off with more adapted concepts less prone to misunderstandings.

      Verb vs Noun:
      Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something.=C2=A0
      The grant (noun) definition directly derives from the verb : "something granted ..."

      I personally=C2=A0have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perha= ps from the word Client, but that's a different issue).
      By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types= " (whatever that means).=C2= =A0

      Dick summarized well the reasons why he uses GS instead of AS :=C2=A0
      1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
      2) grant =3D larger in scope than AS (not only authorization), as it at least includes idclaims=C2=A0+ other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick

      As for "Client", if most= people think it is problematic, it seems a good reason to change if we find a better alternative.=C2=A0
      Quoting Dick again: "Th= e confusion in my experience usually stems from people working=C2=A0with software=C2= =A0that is acting in multiple=C2=A0roles. IE, the software=C2=A0that is acting = as a=C2=A0client=C2= =A0in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view=C2=A0clients=C2=A0as being the software the user is using -- although it may not be acting as a=C2= =A0client=C2=A0in the oauth context." and later "I do agree that i= t is not the best term in GNAP. Primarily because GNAP is a combination of the=C2=A0client= =C2=A0from OAuth 2, and the relying party from OIDC."

      So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis).=C2=A0

      Cheers
      Fabien




      On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.= tonge@moneyhub.com> wrote:
      I would be against using "grant" as = both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant&qu= ot; is in the verb: "granted").=

      Using it as both a verb and a noun will be confusing and less accessible.

      I think it will be confusing to say "Th= e Grant Server issues a grant to the Grant Client representing access that has been granted"

      Whether the access takes place via a token being returned and used at a resource server, or "claims&q= uot; that are directly returned from the "Grant Server" = I think should be largely irrelevant when it comes to the naming of the roles.

      In almost all use cases that I have seen the "Grant Server&qu= ot; is making a policy based decision "to grant&q= uot; access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
      =C2=A0- identity=C2=A0attributes for the end user
      =C2=A0- verify=C2=A0an identity attribute (e.g. that user is over 18)
      =C2=A0- all users phot= os at resource server X
      =C2=A0- a single photo with id 12345 at resource server Y
      =C2=A0- resource of ty= pe X at any resource server that trusts the Grant Server
      =C2=A0- call a payment API with specific properties (e.g. amount < 5)
      =C2=A0- call a file storage API
      =C2=A0- call a "c= ontract signing" API with specific properties (e.g. contract hash of xxx,)
      =C2=A0
      While "client&quo= t; is problematic, it does now have wide spread usage, so perhaps we are stuck with it.=C2=A0<= br>
      However I agree with Justin and think "Grant Client" = makes things more confusing.

      What is wrong with keeping "Client"= ; and "Authorization Server"?=C2=A0

      Dave




      Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA")= . Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at=C2=A0https://register.fca.org.uk/= . Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

      DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.



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



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


      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/mailman/listi= nfo/txauth
      --00000000000062f00305acf96025-- From nobody Sun Aug 16 01:02:36 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 493553A084A for ; Sun, 16 Aug 2020 01:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_FONT_FACE_BAD=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 (1024-bit key) header.d=rhosys.ch 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 7QUjKgEdBflY for ; Sun, 16 Aug 2020 01:02:31 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 65CB83A0796 for ; Sun, 16 Aug 2020 01:02:31 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id d14so12297822qke.13 for ; Sun, 16 Aug 2020 01:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aA5rWRCpeeROYRr59Lv/mr9mRw28hb9VhHIHsUSWfgY=; b=naxPfsoP3Bo8CkLZX4NsTGBkow/kmnjgv1X23aoTsXFHDyeOlVu/VT1zSRLL3NcFHz 7f6W2Hq92QCIVPdNpsnJlSXbfK5FvBdGW7cLLEcrCDX2hUGutnp+9AbzjHJRhXAtTjLD coRqfA4F4toyKTneUwrQ6FleU8/OaYkKO7QO4= 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=aA5rWRCpeeROYRr59Lv/mr9mRw28hb9VhHIHsUSWfgY=; b=I11fnro48Ti4262p3ljSOikzwc6DfzoA24n2WqQXq3puRKEFgG8GUz9SRKdWFeYXZl BzKgina8zfrv7/x/g/QTzSPs3fDhka2UPMJLv+w7I+4urPVVafWcWNL75JCaO+t4+6n9 VPMxMwHyflOQx1bSDUzkmUAND5qNabSHAMz2uP+e20bvxUjZKY7rjxTtPGA+yzS1LGDU Xa/EAf7cTZr4DmeX2xqg9cdBuq3du3MJKhxlNqWenWmidLbWSZrSZpE0d3hNyHpEiufX B82rRjLTFp+mJzaltGhzEwhPWOi1RjdI5HGwNX4S7Utfo5G1w52V9LqdFtiJ1e0YPcDr 23cg== X-Gm-Message-State: AOAM530bVpRLJM3cIyaaGldcQXDvt8lcDlGVRB+IAlC7mEAS1cdGSjc/ k3ngFYn1W47apW+ceLHO63nHE9peX/kNryDPI920 X-Google-Smtp-Source: ABdhPJySijDsW2upb+7IMmvdXlFXCMRh4Yxm1Ml6totII7cdMoKSCfVcpmvKv0vVJUgOjVBYbbzqS98Nu0yRXKeQZ8g= X-Received: by 2002:a05:620a:21c1:: with SMTP id h1mr8436112qka.178.1597564950128; Sun, 16 Aug 2020 01:02:30 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> <3187cf72-88c2-89fb-34a3-4b376f3d7411@free.fr> <86953978-352d-a4a1-7368-141e0fc5c95e@free.fr> <006F9B91-D665-407C-A620-7038CD2611BA@mit.edu> In-Reply-To: From: Warren Parad Date: Sun, 16 Aug 2020 10:02:18 +0200 Message-ID: To: Fabien Imbault Cc: Denis , Francis Pouatcha , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000005bc5a405acfa133a" Archived-At: Subject: Re: [GNAP] Terminology - into Github Issues 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: Sun, 16 Aug 2020 08:02:34 -0000 --0000000000005bc5a405acfa133a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well said! +1 for using the right medium for collaboration. I too have found email for a lot of discussions to be challenging to follow and keep track of important details. On Sun, Aug 16, 2020, 09:12 Fabien Imbault wrote= : > +1 on creating a durable resource for this. > > As with the core spec, doesn't mean we can't discuss on the mailing list. > > Fabien > > Le ven. 14 ao=C3=BBt 2020 =C3=A0 17:33, Denis a =C3= =A9crit : > >> Hello Francis, >> >> - 1. >> >> The mailing list is the usual way to exchange short information. The use >> of the wiki should be restricted to long contributions. >> You are invited to contribute on the mailing list by proposing both a >> wording and its meaning if a current proposed wording >> does not meet your expectations and whenever possible with a short >> rational. >> >> Denis >> >> We have been having a lot of great suggestions and discussion in the lis= t >> on terms. As we go on, a lot of knowledge gets buried in the mailing >> archives. This why i suggest we use the use cases github wiki to: >> >> - start compiling discussions on single terms into issues (tickets), >> - also create a ticket for each use case, either linking the wiki page, >> >> The wiki page will be used to hold the last consolidated state of the >> definition or use case. >> >> Using tickets to complement wiki pages will allow us to: >> - move valuable contributions on each word or use case to the comment >> section of the corresponding ticket. >> - allow contributors or visitors to read the summary of what was >> discussed on a term (resp. use case) before proceeding with additional >> comments/questions. >> - Help focus toward reusable content. >> >> What do you think? >> >> Best regards >> /Francis >> >> On Fri, Aug 14, 2020 at 10:30 AM Justin Richer wrote: >> >>> +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps =E2= =80=9C operator=E2=80=9D >>> as the role they play when, you know, operating the . (Where >>> should still have a more specific name.) >>> >>> =E2=80=94 Justin >>> >>> On Aug 14, 2020, at 8:23 AM, Fabien Imbault >>> wrote: >>> >>> Hi Denis, >>> >>> Thanks for your feedback. >>> Comments inline (marked with FI). >>> >>> Fabien >>> >>> On Fri, Aug 14, 2020 at 12:02 PM Denis >> > wrote: >>> >>>> Hi Fabien, >>>> >>>> Thank you for your inputs, a ball is finally rolling. >>>> >>>> An attempt. >>>> >>>> I would add upfront: User =3D human person >>>> >>>> FI : then end-user is clearer if you want to indicate specifically a >>> human user. One can also create system users. >>> >>>> * =3D application that requests access to Resource Servers (RS= ) >>>> through a Grant Server (GS). * >>>> Examples: a web server, a browser-based app, a mobile app, an IoT >>>> device. >>>> >>>> A few explanations: "through" does not sound appropriate since it coul= d >>>> be interpreted as the GS being necessarilly placed between the Client = and >>>> the RS. >>>> In addition, more than one GS ma= y >>>> be necessary. >>>> >>>> My proposal: * =3D application that requests access to Resour= ce >>>> Servers (RS) **on behalf of a User by using one or more Grant Servers >>>> (GS) * >>>> *Examples: a web server, a browser-based app, a mobile app.* >>>> >>>> FI: agreed. >>> >>>> >>>> *GS =3D computing service that manages the grant lifecycle to a >>>> on behalf of a Resource Controler (RC).* >>>> Note : for privacy reasons, the GS may be issuing grants without >>>> knowledge of which resources are requested. >>>> >>>> I dislike "*on behalf of a Resource Controler (RC)*". The GS may be >>>> fully ignorant of the existence of the RSs and hence of the RCs. >>>> In addition, "*grant life cycle*" is undefined. >>>> >>>> My proposal: *GS =3D server issuing access tokens to a Client after >>>> successfully authenticating the User* >>>> >>>> >>>> *Note 1: for privacy reasons, the GS may be issuing access tokens >>>> without the knowledge of which resources are requested. Note 2: a GS i= s >>>> able to disclose to a User the User attributes that it manages. * >>>> >>>> FI: I find the new definition less clear. It's not because you don't >>> know which RS is called that we shouldn't say the decision is made by t= he >>> RC. >>> "grant life cycle" is indeed currently undefined, what i had in mind is >>> basically the grant flow from the GNAP protocol, possibly also includin= g >>> revocation etc. >>> Not sure why Note 2 is important to put here. >>> >>> >>>> *RS =3D computing service that grants access only if its Resource >>>> Controler (RC) consents.* >>>> Note : the consent may involve a human interaction or may be automated >>>> based on access control policies. >>>> >>>> I dislike "*its Resource Controler (RC) consents" *because it may let >>>> think that a human person always needs to consent. >>>> >>>> My proposal: *R* >>>> *S =3D server hosting protected resources, capable of accepting and >>>> responding to protected resource requests >>>> when access tokens are being used* >>>> >>>> FI : that is why I suggested a note to make sure it is correctly >>> understood. I'm not sure the proposed alternative is clearer. >>> >>>> >>>> *RC =3D entity which is controlling the access to a protected resource= . * >>>> Note : a RC may be manually operated by a human or delegated to a >>>> machine, partially or completely. >>>> >>>> A RC is not an entity but a function. I would also place the machine >>>> case first. >>>> >>>> My proposal: >>>> *RC =3D function tightly coupled with a RS which controls the accesses= to >>>> a protected resource * Note : the function may >>>> be operated either by a machine or by a human person or by some combin= ation >>>> of both. >>>> >>>> FI : your proposition on the note makes it much better. On the main >>> definition, I'm not sure what you mean by function, as a result I'm not >>> sure a reader would understand. Why do you need to say "tightly coupled= ?" >>> >>>> *Consent =3D the process of asking a RC to accept or decline based on = a >>>> grant request presentation, resulting in either a =E2=80=9Cyes=E2=80= =9D or =E2=80=9Cno=E2=80=9D consent >>>> decision.* >>>> >>>> I would instead speak of the "User Consent". The User Consent is a set >>>> of choices among a proposed set of choices. It is not simply a "yes" o= r >>>> "no" consent decision. >>>> >>>> My proposal: *User Consent =3D ability for a User, after being informe= d, >>>> of choosing to release or not to a RS some attributes contained in one= or >>>> more access tokens* >>>> >>>> >>> FI: this may be misleading I think. The consent is done by a RC (or in >>> OAuth terms, RO), not the application user. >>> I agree there may be a combination of consent decisions, but I think >>> it's important to say that in the end for each individual choice, you d= o >>> have a yes/no decision. >>> >>>> >>>> Denis >>>> >>>> >>>> Fabien >>>> >>>> On Thu, Aug 13, 2020 at 3:55 PM Denis wrote: >>>> >>>>> Fabien, >>>>> >>>>> IMHO, nothing is wrong with keeping "Client" since it has a wide >>>>> spread usage >>>>> ... but only as long as we can agree on a short and a clear definitio= n >>>>> for it. >>>>> >>>>> I can provide the beginning of such a definition: " application ..." >>>>> >>>>> If someone could go a little bit further, this would help. :-) >>>>> >>>>> A similar argumentation for GS. It could be used but only as long as >>>>> we can agree on a short and a clear definition for it. >>>>> Any proposal ? >>>>> >>>>> Denis >>>>> >>>>> Hi, >>>>> >>>>> Nothing inherently wrong with Client/AS, which has worked for years i= n >>>>> the context of OAuth2. The question is to know whether we can build t= he new >>>>> protocol with the same concepts and deal with their known limitations= , or >>>>> if we're better off with more adapted concepts less prone to >>>>> misunderstandings. >>>>> >>>>> Verb vs Noun: >>>>> Problem is that the grant (noun) can only be understood if there is a >>>>> grant(verb), i.e. some action that grants something. >>>>> The grant (noun) definition directly derives from the verb : >>>>> "something granted ..." >>>>> >>>>> I personally have no issue even with the fairly convoluted "The Grant >>>>> Server issues a grant to the Grant Client representing access that ha= s been >>>>> granted" (except perhaps from the word Client, but that's a different >>>>> issue). >>>>> By the way, grant is nothing new, it's used extensively in OAuth2 as >>>>> "grant types" (whatever that means). >>>>> >>>>> Dick summarized well the reasons why he uses GS instead of AS : >>>>> 1) "grant" is in the working group name (a weaker reason, but still >>>>> has been approved). Question: would our reasoning if the protocol end= ed up >>>>> being called OAuth3? >>>>> 2) grant =3D larger in scope than AS (not only authorization), as it = at >>>>> least includes idclaims + other use cases like payment (?) - no conse= nsus, >>>>> see difference in appreciation between Justin and Dick >>>>> >>>>> As for "Client", if most people think it is problematic, it seems a >>>>> good reason to change if we find a better alternative. >>>>> Quoting Dick again: "The confusion in my experience usually stems >>>>> from people working with software that is acting in multiple roles. I= E, the >>>>> software that is acting as a client in once context, is also acting >>>>> as an RS in other contexts, or even acting as an AS. The other confus= ion is >>>>> that people view clients as being the software the user is using -- >>>>> although it may not be acting as a client in the oauth context." and >>>>> later "I do agree that it is not the best term in GNAP. Primarily bec= ause >>>>> GNAP is a combination of the client from OAuth 2, and the relying >>>>> party from OIDC." >>>>> >>>>> So far there's no consensus however, recent tries: Initiating >>>>> Application (Denis), Orchestrator (Francis). >>>>> >>>>> Cheers >>>>> Fabien >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge >>>>> wrote: >>>>> >>>>>> I would be against using "grant" as both a verb and a noun and stick >>>>>> purely with one or the other. (In the charter the only use of "grant= " is in >>>>>> the verb: "granted"). >>>>>> >>>>>> Using it as both a verb and a noun will be confusing and less >>>>>> accessible. >>>>>> >>>>>> I think it will be confusing to say "The Grant Server issues a grant >>>>>> to the Grant Client representing access that has been granted" >>>>>> >>>>>> Whether the access takes place via a token being returned and used a= t >>>>>> a resource server, or "claims" that are directly returned from the "= Grant >>>>>> Server" I think should be largely irrelevant when it comes to the na= ming of >>>>>> the roles. >>>>>> >>>>>> In almost all use cases that I have seen the "Grant Server" is makin= g >>>>>> a policy based decision "to grant" access to requested resource(s). = To me, >>>>>> that is the fundamental operation happening. I think nearly all use = cases >>>>>> can be applied to that, e.g. the GS grants access to >>>>>> - identity attributes for the end user >>>>>> - verify an identity attribute (e.g. that user is over 18) >>>>>> - all users photos at resource server X >>>>>> - a single photo with id 12345 at resource server Y >>>>>> - resource of type X at any resource server that trusts the Grant >>>>>> Server >>>>>> - call a payment API with specific properties (e.g. amount < 5) >>>>>> - call a file storage API >>>>>> - call a "contract signing" API with specific properties (e.g. >>>>>> contract hash of xxx,) >>>>>> >>>>>> While "client" is problematic, it does now have wide spread usage, s= o >>>>>> perhaps we are stuck with it. >>>>>> However I agree with Justin and think "Grant Client" makes things >>>>>> more confusing. >>>>>> >>>>>> What is wrong with keeping "Client" and "Authorization Server"? >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA").. Moneyhub Financial Technology is entered= on the >>>>>> Financial Services Register (FRN 809360) at >>>>>> https://register.fca.org.uk/.. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772. >>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpris= e, Regus >>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> >>>>> >>>> -- >>>> 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/ >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005bc5a405acfa133a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Well said! +1 for using the right medium for collaboratio= n. I too have found email for a lot of discussions to be challenging to fol= low and keep track of important details.

      On Sun, Aug 16, 2020, 09:12 Fabien = Imbault <fabien.imbault@gmai= l.com> wrote:
      +1 on creating a durable resource f= or this.=C2=A0

      As with t= he core spec, doesn't mean we can't discuss on the mailing list.=C2= =A0

      Fabien
      Le ven. = 14 ao=C3=BBt 2020 =C3=A0 17:33, Denis <denis.ietf@free.fr= > a =C3=A9crit=C2=A0:
      =20 =20 =20
      Hello Francis,

      - 1.

      The mailing list is the usual way to exchange short information. The use of the wiki should be restricted to long contributions.
      You are invited to contribute on the mailing list by proposing both a wording and its meaning if a current proposed wording
      does not meet your expectations and whenever possible with a short rational.

      Denis

      =20
      We have been having a lot of great suggestions and discussion in the list on terms. As we go on, a lot of knowledge gets buried=C2=A0in the mailing archives. This why i suggest we use the use cases github wiki to:

      - start compiling discussions on single terms into issues (tickets),
      - also create a ticket for each use case, either linking the wiki page,

      The wiki page will be used to hold the last consolidated=C2=A0state of the definition or use case.

      Using tickets to complement wiki pages will allow us to:
      - move valuable contributions on each word or use case to the comment section of the corresponding ticket.
      - allow contributors or visitors to read the summary=C2=A0of what was discussed on a term (resp. use case) before proceeding with additional comments/questions.
      - Help focus=C2=A0toward reusable content.

      What do you=C2=A0think?

      Best regards
      /Francis

      On Fri, Aug 14, 2020 at 10:30 AM Justin Richer <jricher@mit.edu> wrote:
      +1 for =E2=80=9Cend user=E2=80=9D as the human person, and perhaps =E2=80=9C<client> operato= r=E2=80=9D as the role they play when, you know, operating the <client>. (Where <client> should still have a more specific name.)

      =C2=A0=E2=80=94 Justin


      Hi Denis,=C2=A0

      Thanks for your feedback.=C2=A0
      Comments inline (marked with FI).

      Fabien

      On Fri, Aug 14, 2020 at 12:02 PM Denis <denis..ietf@free.fr> wrote:
      Hi Fabien,

      Thank you for your inputs, a ball is finally rolling.

      An attempt.
      I would add upfront: User =3D=C2= =A0 human person
      FI : then end-user is clearer if you want to indicate specifically a human user. One can also create system users.
      <Client> =3D application that requests access to Resource Servers (RS) through a Grant Server (GS).=C2=A0=C2=A0
      Examples: a=C2=A0web server, a browser-based app, a mobile app, an IoT device.

      A few explanations: "through" = does not sound appropriate since it could be interpreted as the GS being necessarilly placed between the Client and the RS.=C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition, more than one GS may be necessary.

      My proposal:=C2=A0=C2=A0= <Client> =3D application that requests access to Resource Servers (RS)=C2=A0on behalf of a=C2=A0User=C2=A0by using one or more Grant Servers (GS)=C2=A0
      Examples: a=C2=A0web server, a browser-based app, a mobile app.

      FI: agreed.=C2=A0=C2=A0

      GS =3D computing service that manages the grant lifecycle=C2=A0to= a <Client> on behalf of a Resource Controler (RC).
      Note : for privacy reasons, the GS may be issuing grants without knowledge of which resources are requested.

      I dislike "on behalf of a Resour= ce Controler (RC)". The GS may be fully ignorant of the existence of the RSs and hence of the RCs.
      In addition, "grant life cycle" is undefined.

      My proposal:=C2=A0=C2=A0= GS =3D=C2=A0server issuing access tokens to a Client after successfully authenticating the User
      Note 1: for privacy reasons, the GS may be issuing access tokens without the knowledge of which resources are requested.
      Note 2: a GS is able to disclose to a User the User attributes that it manages.=C2=A0=C2=A0

      FI: I find the new definition less clear. It's not because you don't know which R= S is called that we shouldn't say the decision i= s made by the RC.=C2=A0
      "grant life cycle" is indeed curre= ntly undefined, what i had in mind is basically the grant flow from the GNAP protocol, possibly also including revocation etc.
      Not sure why Note 2 is important to put here.
      =C2=A0
      RS =3D computing service that grants access only if its Resource Controler (RC) consents.
      Note : the consent may involve a human interaction or may be automated based on access control policies.
      I dislike "its Resource Controler (RC) consents"=C2=A0= because it may let think that a human person always needs to consent.

      My proposal:=C2=A0RS= =3D server hosting protected resources, capable of accepting and responding to protected resource requests=C2=A0
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 when access tokens are being used
      FI : that is why I suggested a note to make sure it is correctly understood. I'm not sure the proposed alternative is clearer.=C2=A0

      RC =3D entity which is controlling the access to a protected resource.=C2=A0
      Note : a RC may be manually operated by a human or delegated to a machine, partially or completely.

      A RC is not an entity but a function. I would also place the machine case first.

      My proposal:=C2=A0RC =3D function tightly coupled with a RS which controls the accesses to a protected resource
      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Note : the function may be operated either by a machine or by a human person or by some combination of both.

      FI : your proposition on the note makes it much better. On the main definition, I'm not sure what you mean by function, as a result I'm not sure a reader would understand. Why do you need to say "tightl= y coupled?"=C2=A0
      Consent =3D the process of asking a RC to accept or decline based on a grant request presentation, resulting in either a =E2=80=9Cyes=E2=80=9D or = =E2=80=9Cno=E2=80=9D consent decision.

      I would instead speak of the "User Consent". The User Consent is a set = of choices among a proposed set of choices. It is not simply a "yes&quo= t; or "no" consent decision.

      My proposal:=C2=A0User Consent =3D ability for a User, after being informed, of choosing to release or not to a RS some attributes contained in one or more access tokens


      FI: this may be misleading I think. The consent is done by a RC (or in OAuth terms, RO), not the application user.=C2=A0
      I agree there may be a combination of consent decisions, but I think it's important to say that in the end for each individual choice, you do have a yes/no decision.=C2=A0


      Denis


      Fabien

      On Thu, Aug 13, 2020 at 3:55 PM Denis <denis.ietf@fr= ee.fr> wrote:
      Fabien,

      IMHO, nothing is wrong with keeping "Client" sinc= e it has a wide spread usage
      ... but only as long as we can agree on a short and a clear definition for it.      =

      I can provide the beginning of such a definition: " application ..."

      If someone could go a little bit further, this would help. :-)

      A similar argumentation for GS.=C2=A0 It could be used but<= span>=C2=A0only as = long as we can agree on a short and a clear definition for it.
      Any proposal ?

      Denis

      Hi,

      Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we'r= e better off with more adapted concepts less prone to misunderstandings.

      Verb vs Noun:
      Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something.=C2=A0
      The grant (noun) definition directly derives from the verb : "something granted ..."

      I personally=C2=A0have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perha= ps from the word Client, but that's a different issue).
      By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types= " (whatever that means).=C2= =A0

      Dick summarized well the reasons why he uses GS instead of AS :=C2=A0
      1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3?
      2) grant =3D larger in scope than AS (not only authorization), as it at least includes idclaims=C2=A0+ other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick

      As for "Client", if most= people think it is problematic, it seems a good reason to change if we find a better alternative.=C2=A0
      Quoting Dick again: "Th= e confusion in my experience usually stems from people working=C2=A0with software=C2= =A0that is acting in multiple=C2=A0roles. IE, the software=C2=A0that is acting = as a=C2=A0client=C2= =A0in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view=C2=A0clients=C2=A0as being the software the user is using -- although it may not be acting as a=C2= =A0client=C2=A0in the oauth context." and later "I do agree that i= t is not the best term in GNAP. Primarily because GNAP is a combination of the=C2=A0client= =C2=A0from OAuth 2, and the relying party from OIDC."

      So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis).=C2=A0

      Cheers
      Fabien




      On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
      I would be against using "grant" as = both a verb and a noun and stick purely with one or the other. (In the charter the only use of "grant&qu= ot; is in the verb: "granted").=

      Using it as both a verb and a noun will be confusing and less accessible.

      I think it will be confusing to say "Th= e Grant Server issues a grant to the Grant Client representing access that has been granted"

      Whether the access takes place via a token being returned and used at a resource server, or "claims&q= uot; that are directly returned from the "Grant Server" = I think should be largely irrelevant when it comes to the naming of the roles.

      In almost all use cases that I have seen the "Grant Server&qu= ot; is making a policy based decision "to grant&q= uot; access to requested resource(s). To me, that is the fundamental operation happening. I think nearly all use cases can be applied to that, e.g. the GS grants access to
      =C2=A0- identity=C2=A0attributes for the end user
      =C2=A0- verify=C2=A0an identity attribute (e.g. that user is over 18)
      =C2=A0- all users phot= os at resource server X
      =C2=A0- a single photo with id 12345 at resource server Y
      =C2=A0- resource of ty= pe X at any resource server that trusts the Grant Server
      =C2=A0- call a payment API with specific properties (e.g. amount < 5)
      =C2=A0- call a file storage API
      =C2=A0- call a "c= ontract signing" API with specific properties (e.g. contract hash of xxx,)
      =C2=A0
      While "client&quo= t; is problematic, it does now have wide spread usage, so perhaps we are stuck with it.=C2=A0<= br>
      However I agree with Justin and think "Grant Client" = makes things more confusing.

      What is wrong with keeping "Client"= ; and "Authorization Server"?=C2=A0

      Dave




      Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA")= .. Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at=C2=A0https://register.fca.org.uk/= .. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

      DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.



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



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


      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/ma= ilman/listinfo/txauth
      --
      TXAuth mailing list
      TXA= uth@ietf.org
      https://www.ietf.org/mailman/listinfo/txauth<= /a>
      --0000000000005bc5a405acfa133a-- From nobody Sun Aug 16 13:28:28 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 8D4633A0C78 for ; Sun, 16 Aug 2020 13:28:26 -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 W5zmmG8SMtIS for ; Sun, 16 Aug 2020 13:28:23 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 8B7973A110B for ; Sun, 16 Aug 2020 13:28:22 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id t23so15252044ljc.3 for ; Sun, 16 Aug 2020 13:28:22 -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=AGhS9FJcoA+X7TrV4a+p4QP65CaVilId43LH4okn7zA=; b=LQEjXr/weZWNva6eEYinp9aLcGqwu4O1QBLumno/rcVvjGHXhsaGcBRLXjtjYEx5FX id6xB8IK5LuGpGu6p8ReqMYMWwQrjg6i56KLhlU9EBuUWze6/VF2Z8e02ros5zeDVqas mfqtyM5wKpJuCsApdhb7O6Uwb7NezppZ/ZPQbDgOLmlgwnAhiU7xI+rbi1i/oZtNOqg5 zAqiEYGQ2p6Ttxhf4e3bSyFjIezjJ9i8yCBJ83utXP8aUfstKyzrWU0IkLNGkyek6Rhp iOGAC+gfAWNmKv8+AE5m0qCp2/GXpv0IW/p1m+Ji+11NgUQ523TT9ihY5LeK37m6w8lQ UeXg== 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=AGhS9FJcoA+X7TrV4a+p4QP65CaVilId43LH4okn7zA=; b=ElhxYTfFLrIlrtKyJDUgHquejK6i2yfn73jmu/kmD+bU8Bs3A07vFsXA8MvbVB0NVT +YPRA0ezh1j8IeYVW/FkyYBI6RjWnUQb1r0H9p1sa2Jvq+2oxTJxY6aTSxbES/s6C8p3 dVEQTovKMWPMtTi5gAmcwcuVVKRDTezcJk4O35UBkkupl+XPw8xE3mnOIKdW89jjYVSA BjdlYLCdmWHYoo5M7GRlN8dNSlhBLIw3wilnq1Wyfby0bTN9rguHNpH+0CovxCSki6fb sd6xBjtUAsET6bBPSBR6YmLgi/zqTtAGVr+2Rf+tLQK00Uc+pP4tHxQkptiXYrpxt2DF +Iiw== X-Gm-Message-State: AOAM530q3ahyvF7JFxYr7vZaFVRKTihKl/tSDcynoG96wFJEVpjygjop 7mUTVpRgE81+nPZG+d28UCbmdPXazx2B/8Y6f54= X-Google-Smtp-Source: ABdhPJxKwxe2O76Owl0Hm3lDPcrTRC+IUwuPuzeMEsYiNS/2h5GWEk4oYw+Rr3lWzRJ9f2Pxd5q84dp/tkSSYxn1RvE= X-Received: by 2002:a2e:b8cb:: with SMTP id s11mr6330760ljp.110.1597609700275; Sun, 16 Aug 2020 13:28:20 -0700 (PDT) MIME-Version: 1.0 References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b06d5849bf941d69376d1d7efbc4950@oc11expo18.exchange.mit.edu> <49B10559-0FB2-4B80-81C6-6F25F76F2ED8@mit.edu> <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> In-Reply-To: <58369087-2bfa-152a-ea8d-22f32424aefb@free.fr> From: Dick Hardt Date: Sun, 16 Aug 2020 13:27:43 -0700 Message-ID: To: Denis Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000acc35f05ad047ef8" Archived-At: Subject: Re: [GNAP] User consent 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: Sun, 16 Aug 2020 20:28:27 -0000 --000000000000acc35f05ad047ef8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Denis, a mathematical expression is not a user experience. While we may be able to standardize the result of a user experience, that is not the same thing. On Fri, Aug 14, 2020 at 3:14 AM Denis wrote: > This is a new thread built from "Revisiting the photo sharing example (a > driving use case for the creation of OAuth)" > > Hi Dick, > > I don't see how we can technically standardize a user experience, and it > is not clear why a standard would be needed for interoperability. > > I already wrote a proposal and made it available to the mailing list. > > An access will be granted by a RS based on an mathematical expression > which is formed using some combination of AND and OR conditions. > > Examples of combinations: > > *condition 1* AND > *condition 2 condition 1* OR *condition 2* > (*condition 1* AND *condition 2)* OR > *condition 3 (condition 1* OR *condition 2)* AND *condition 3* > > The following notation is being used for the *conditions*: > > *condition x* =3D { AS identifier + set of attributes types } > > Each RS internally constructs an *authorization table* with the following > content: > > 1=C2=B0 For the "authentication" operation: either FIDO U2F or a mathema= tical > expression using conditions; > > 2=C2=B0 For any other operation: a mathematical expression using conditi= ons. > > Given the operation selected by the client, the RS returns the appropriat= e > mathematical expression and only the associated conditions > used in that mathematical expression. The User may then decide whether > they are appropriate to him or not. > > In many jurisdictions there are regulations regarding what information > needs to be conveyed to a user, and potentially a consent requirement, > for example a site explaining its use of cookies -- but I don't see how > IETF would play a role in that. > > On a related note, the browsers attempted to standardize the username / > password prompt, and that has been rejected by pretty much every site. > The only site I've visited in the last decade that has used the browsers' > built in username / password prompt was the W3C site -- and it was a > frustrating > experience since there was no button for account recovery -- it would jus= t > keep popping up. > > What I am proposing is unrelated to the two above cases you mention. > > Denis > > > > =E1=90=A7 > > On Thu, Aug 13, 2020 at 10:29 AM Denis wrote: > >> Dick, >> >> I think Tom's objection, and I agree with it, is that humans don't >> interact in bits and bytes. >> >> I think it is useful to separate human interactions with software from >> software interactions with software. >> The latter we can standardize, the former we can call out as part of the >> overall process, but it is not something >> that is testable or required for interop, so I would argue human to >> software interactions are NOT part of the protocol. >> >> I disagree. A set of a choices should be presented by the RS to the >> Client in a standardized way. The choices made by the user >> should be locally recorded by the Client, hence the RS does not need to >> be informed of these choices. The RS will only know >> the end result of these choices when/if it gets back one or more access >> tokens. >> >> Human to software interactions should be part of the protocol. >> >> RS to Client: a set of choices >> >> Client to RS: Done (choices have been done by the user). >> >> Denis >> >> >> >> =E1=90=A7 >> >> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer wrote: >> >>> It=E2=80=99s a role fulfilled by a person, so I=E2=80=99m not sure wher= e the objection >>> you=E2=80=99re raising comes from. >>> >>> Also, whatever roles we define here, whether software or human-ware, >>> they need to be related to the protocol. >>> >>> =E2=80=94 Justin >>> >>> On Aug 13, 2020, at 10:59 AM, Tom Jones >>> wrote: >>> >>> I strong object to the objectification of human users. It is way past >>> time that the IETF becaume user oriented instead of web service oriente= d. >>> users are human in my language. >>> Peace ..tom >>> >>> >>> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer wrote: >>> >>>> If defined as the party operating the client software, then the user i= s >>>> a role. I believe this is more accurate and inclusive than the definit= ion >>>> you have proposed with the user as an entity. >>>> >>>> - Justin >>>> ________________________________________ >>>> From: Dick Hardt [dick.hardt@gmail.com] >>>> Sent: Tuesday, August 11, 2020 6:21 PM >>>> To: Francis Pouatcha >>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org >>>> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a >>>> driving use case for the creation of OAuth) >>>> >>>> Hi Francis >>>> >>>> The user is an entity, not a role in the protocol in how I am defining >>>> roles, so steps (1) and (7) are confusing to me on what is happening. >>>> >>>> I also think that (2) could be an extension to GNAP, rather than part >>>> of the core protocol. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha >>> > wrote: >>>> In this context, I suggest we pick some words to work with, and sharpe= n >>>> them as we move on, discover and map new use cases to the protocol. >>>> >>>> In this diagram from the original thread ( >>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOG= Nw/), >>>> I replaced the words: >>>> >>>> +-----------+ +--------------+ +----+ +----+ >>>> +---------------------+ >>>> | Requestor | | Orchestrator | | | | GS | | Resource >>>> Controller | >>>> | was | | was | | RS | | or | | was >>>> | >>>> | User | | Client | | | | AS | | Resource >>>> Owner | >>>> +-----------+ +--------------+ +----+ +----+ >>>> +---------------------+ >>>> |(1) ServiceRequest | | | | >>>> |---------------------->| | | | >>>> | |(2) ServiceIntent:AuthZChallenge | >>>> | |<---------->| | | >>>> | | | | | >>>> | |(3) AuthZRequest(AuthZChallenge) | >>>> | |------------------->| | >>>> | | | |(4) ConsentRequest:Gra= nt >>>> | | | |<-------------->| >>>> | |(5) GrantAccess(AuthZ) | >>>> | |<-------------------| | >>>> | | | | | >>>> | |(6) ServiceRequest(AuthZ):ServiceResponse >>>> | |<---------->| | | >>>> |(7) ServiceResponse | | | | >>>> |<----------------------| | | | >>>> + + + + + >>>> >>>> The purpose of the GNAP protocol is to help negotiate access to a >>>> protected resource. It starts with a requestor delegating activity to = an >>>> orchestrator. These are all roles, no entities. Let focus on mapping t= he >>>> use cases to the protocol roles and interactions so wwe can discover w= hat >>>> is missing. >>>> >>>> It seems cumbersome to use it in discussions as it is impossible to >>>> give the word "Client" a clear definition. >>>> >>>> We can mention in the final document, that the "Orchestrator" (or >>>> whatever word we finally use) plays the same role as the "Client" in o= Auth2. >>>> >>>> Best regards. >>>> /Francis >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt >>> dick.hardt@gmail.com>> wrote: >>>> I agree with Justin. Redefining well used terms will lead to >>>> significant confusion. If we have a different role than what we have h= ad in >>>> the past, then that role should have a name not being used already in = OAuth >>>> or OIDC. >>>> >>>> Given what we have learned, and my own experience explaining what a >>>> Client is, and is not, improving the definition for Client could prove >>>> useful. I am not suggesting the term be redefined, but clarified. >>>> >>>> For example, clarifying that a Client is a role an entity plays in the >>>> protocol, and that the same entity may play other roles at other times= , or >>>> some other language to help differentiate between "role" and "entity". >>>> >>>> /Dick >>>> [ >>>> https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20= %3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d50e00dbac3a]=E1=90= =A7 >>>> >>>> >>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer >>> jricher@mit.edu>> wrote: >>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a bet= ter fit, but I=E2=80=99m >>>> not really in favor of taking an existing term and applying a complete= ly >>>> new definition to it. In other words, I would sooner stop using =E2=80= =9Cclient=E2=80=9D >>>> and come up with a new, more specific and accurate term for the role t= han >>>> to define =E2=80=9Cclient=E2=80=9D as meaning something completely dif= ferent. We did this >>>> in going from OAuth 1 to OAuth 2 already, moving from the >>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserve= r=E2=80=9D on its own but instead >>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>> >>>> GNAP can do something similar, in my opinion. But what we can=E2=80=99= t do is >>>> ignore the fact that GNAP is going to be coming up in a world that is >>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t ha= ve a blank >>>> slate to work with, but neither are we bound to use the same terms and >>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 4, 2020, at 3:32 PM, Warren Parad >>> wparad@rhosys.ch>> wrote: >>>> >>>> I think that is fundamentally part of the question: >>>> We are clear that we are producing a protocol that is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion >>>> >>>> If we say that this document assumes OAuth2.0 terminology, then we >>>> should not change the meanings of any definition. If we are saying thi= s >>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the= best >>>> word for the job and ignore conflicting meanings from OAuth 2.0. I hav= e a >>>> lot of first hand experience of industries "ruining words", and attemp= ting >>>> to side-step the problem rather than redefining the word just confuses >>>> everyone as everyone forgets the original meaning as new documents com= e >>>> out, but the confusion with the use of a non-obvious word continues. >>>> >>>> Food for thought. >>>> - Warren >>>> >>>> [ >>>> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZ= OsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hj= uIm9GCeBRRzrSc8kWcUSNtuA >>>> ] >>>> >>>> Warren Parad >>>> Founder, CTO >>>> >>>> Secure your user data and complete your authorization architecture. >>>> Implement Authress. >>>> >>>> >>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk >>> kaduk@mit.edu>> wrote: >>>> Hi Denis, >>>> >>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>> > Hi Justin, >>>> > >>>> > Since you replied in parallel, I will make a response similar to the >>>> one >>>> > I sent to Dick. >>>> > >>>> > > Hi Denis, >>>> > > >>>> > > I think there=E2=80=99s still a problem with the terminology in us= e here. >>>> What >>>> > > you describe as RS2, which might in fact be an RS unto itself, is = a >>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a client= of RS1/. What you >>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth world= , but it is not at >>>> > > all the same as an OAuth client. I appreciate your mapping of the >>>> > > entities below, but it makes it difficult to hold a discussion if = we >>>> > > aren=E2=80=99t using the same terms. >>>> > > >>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can >>>> define >>>> > > our own terms. The bad news is that this is really hard to do. >>>> > > >>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new >>>> definitions, >>>> > > but we=E2=80=99ve got a chance to be more precise with how we defi= ne things. >>>> > >>>> > In the ISO context, each document must define its own terminology. T= he >>>> > boiler plate for RFCs does not mandate a terminology or definitions >>>> section >>>> > but does not prevent it either. The vocabulary is limited and as lon= g >>>> as >>>> > we clearly define what our terms are meaning, we can re-use a term >>>> already >>>> > used in another RFC. This is also the ISO approach. >>>> >>>> Just because we can do something does not necessarily mean that it is = a >>>> good idea to do so. We are clear that we are producing a protocol tha= t >>>> is >>>> conceptually (if not more strongly) related to OAuth 2.0, and reusing >>>> terms >>>> from OAuth 2.0 but with different definitions may lead to unnecessary >>>> confusion. If I understand correctly, a similar reasoning prompted >>>> Dick to >>>> use the term "GS" in XAuth, picking a name that was not already used i= n >>>> OAuth 2.0. >>>> >>>> -Ben >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> 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/ >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --000000000000acc35f05ad047ef8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Denis, a mathematical expression is not a user experi= ence.

      While we may be able to standardize the resu= lt of a user experience, that is not the same thing.=C2=A0

      On Fri, Aug 14, 2= 020 at 3:14 AM Denis <denis.ietf@f= ree.fr> wrote:
      =20 =20 =20
      This is a new thread built from "R= evisiting the photo sharing example (a driving use case for the creation of OAuth)"

      Hi Dick,

      =20
      I don't see how we can technically standardize a user experience, and it is not clear why a standard would be needed for interoperability.

      I already wrote a proposal and made it available to the mailing list.

      An access will be granted b= y a RS based on an mathematical expression which is formed using some combination of AND and OR conditions.

      Examples of combinations:

      condition 1 AND condition= 2
      condition 1       OR condition 2
      (condition 1 AND condition 2= ) OR condition 3
      (condition 1       OR condition 2) AND <= /span>condition 3      =

      The following notation is being used for the conditions:

      condition x =3D { AS identifier + set of attributes types }

      Each RS internally constructs an authorization table with the following content:

      1=C2=B0=C2=A0 For th= e "authentication" operation: either FIDO U2F or a mathematical expression using conditions;

      2=C2=B0=C2=A0 For an= y other operation: a mathematical expression using conditions.

      Given the operation selected by the client, the RS returns the appropriate mathematical expression and only the associated conditions
      used in that mathematical expression. The User may then decide whether they are appropriate to him or not.

      =C2=A0In many jurisdictions there are regulations regarding wh= at information needs to be conveyed to a user, and potentially a consent requirement,
      for example a site explaining its use of cookies -- but I don't see how IETF would play a role in that.=C2=A0

      On a related note, the browsers=C2=A0attempted to standardize the username / password prompt, and that has been rejected by pretty much every site.
      The only site I've visited in the last decade that has used the browsers' built in username / password prompt was the W3C site -- and it was a frustrating
      experience since there was no button for account recovery -- it would just keep popping up.

      What I am proposing is unrelated to the two above cases you mention.

      Denis



      3D""==E1=90=A7

      On Thu, Aug 13, 2020 at 10:29 AM Denis <denis.ietf@free.fr> wrote:
      Dick,

      I think Tom's objection, and I agree wit= h it, is that humans don't interact in bits and bytes.=C2= =A0

      I think it is useful to separate human interactions with software from software interactions with software.
      The latter we can standardize, the former we can call out as part of the overall process, but it is not something
      that is testable or required for interop, so I would argue human to software interactions are NOT part of the protocol.

      I disagree.=C2=A0 A set of a choices should be presented by the RS to the Client in a standardized way. The choices made by the user
      should be locally recorded by the Client, hence the RS does not need to be informed of these choices. The RS will only know
      the end result of these choices when/if it gets back one or more access tokens.

      Human to software interactions should be part of the protocol.

      RS to Client: a set of choices

      Client to RS: Done (choices have been done by the user).

      Denis



      3D""=E1=90=A7

      On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <jricher@mit.edu> wrote:
      It=E2=80=99s a role fulfilled by a person, so I=E2= =80=99m not sure where the objection you=E2=80=99re raising comes f= rom.

      Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

      =C2=A0=E2=80=94 Justin

      On Aug 13, 2020, at 10:59 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

      I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
      users are human in my language.
      Peace ..tom


      On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <jricher@mit.edu> wrote:
      If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity.

      =C2=A0- Justin
      ________________________________________
      From: Dick Hardt [dick.hardt@gmail.com]
      Sent: Tuesday, August 11, 2020 6:21 PM
      To: Francis Pouatcha
      Cc: Justin Richer; Denis; Benjamin James Kaduk; txauth@ietf.org
      Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

      Hi Francis

      The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

      I also think that (2) could be an extension to GNAP, rather than part of the core protocol.





      On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
      In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

      In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_Kimj= OBJqdmQY-JOGNw/), I replaced the words:

      +-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
      | Requestor |=C2=A0 =C2=A0 =C2=A0 | Orc= hestrator |=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | GS |=C2=A0 | R= esource Controller |
      |=C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 |=C2=A0 | RS |=C2=A0 | or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0was=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
      |=C2=A0 User=C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 |=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 |=C2=A0 | AS |=C2=A0 |= =C2=A0 =C2=A0 Resource Owner=C2=A0 =C2=A0|
      +-----------+=C2=A0 =C2=A0 =C2=A0 +----= ----------+=C2=A0 +----+=C2=A0 +----+=C2=A0 +---------------------+
      =C2=A0 |(1) ServiceRequest=C2=A0 =C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |---------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(2) ServiceIntent:AuthZChallenge=C2=A0 =C2= =A0 =C2=A0|
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=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) AuthZRequest(AuthZChallenge)=C2=A0 =C2= =A0 =C2=A0|
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------------------->|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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)= ConsentRequest: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 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|<= ;-------------->|
      =C2=A0 |=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) GrantAccess(AuthZ)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-------------------|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|(6) ServiceRequest(AuthZ):ServiceResponse =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<---------->|=C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |(7) ServiceResponse=C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |<----------------------|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

      The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

      It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clea= r definition.

      We can mention in the final document, that the "Orchestrator&q= uot; (or whatever word we finally use) plays the same role as the "Client= " in oAuth2.

      Best regards.
      /Francis





      On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>= > wrote:
      I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

      Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.

      For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role&q= uot; and "entity".

      /Dick
      [https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBn= bWFpbC5jb20%3D&type=3Dzerocontent&guid=3De48e13f4-2306-4d7c-8654-d5= 0e00dbac3a]=E1=90=A7

      On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:jricher@mit.edu>> wrote:
      I=E2=80=99m in favor of coming up with = a new term that=E2=80=99s a better fit, but I= =E2=80=99m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come= up with a new, more specific and accurate term for the role than to define =E2=80=9Ccl= ient=E2=80=9D as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9C= client=E2=80=9D, but OAuth 2 doesn=E2=80=99t use the term =E2=80=9Cc= onsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorization Server=E2= =80=9D and =E2=80=9CResource Server=E2=80=9D.

      GNAP can do something similar, in my opinion. But what we can=E2=80=99t do i= s ignore the fact that GNAP is going to be coming up in a world that is already permeated=C2=A0 by OAuth 2 and its terminology. We don=E2=80=99t have = a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

      =C2=A0=E2=80=94 Justin

      On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch<mailto:wparad@rhosys.ch>> wrote:

      I think that is fundamentally part of the question:
      We are clear that we are producing a protocol that is
      conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
      from OAuth 2.0 but with different definitions may lead to unnecessary
      confusion

      If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.

      Food for thought.
      - Warren

      [https://lh6.googleusercontent.com/DNiDx1QGIr= SqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45= YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

      Warren Parad
      Founder, CTO

      Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p&g= t;.


      On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
      Hi Denis,

      On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
      > Hi Justin,
      >
      > Since you replied in parallel, I will make a response similar to the one
      > I sent to Dick.
      >
      > > Hi Denis,
      > >
      > > I think there=E2=80=99s still= a problem with the terminology in use here. What
      > > you describe as RS2, which might in fact be an RS unto itself, is a
      > > =E2=80=9CClient=E2=80=9D in O= Auth parlance because it is /a client of RS1/. What you
      > > call a =E2=80=9Cclient=E2=80= =9D has no analogue in the OAuth world, but it is not at
      > > all the same as an OAuth client. I appreciate your mapping of the
      > > entities below, but it makes it difficult to hold a discussion if we
      > > aren=E2=80=99t using the same terms.
      > >
      > > The good news is that this isn=E2=80=99t OAuth, and as a new WG we= can define
      > > our own terms. The bad news is that this is really hard to do.
      > >
      > > In GNAP, we shouldn=E2=80=99t= just re-use existing terms with new definitions,
      > > but we=E2=80=99ve got a chanc= e to be more precise with how we define things.
      >
      > In the ISO context, each document must define its own terminology. The
      > boiler plate for RFCs does not mandate a terminology or definitions section
      > but does not prevent it either. The vocabulary is limited and as long as
      > we clearly define what our terms are meaning, we can re-use a term already
      > used in another RFC. This is also the ISO approach.

      Just because we can do something does not necessarily mean that it is a
      good idea to do so.=C2=A0 We are clear that we are producing a protocol that is
      conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
      from OAuth 2.0 but with different definitions may lead to unnecessary
      confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Dick to
      use the term "GS" in XAuth, p= icking a name that was not already used in
      OAuth 2.0.

      -Ben

      --
      Txauth mailing list
      Txauth@ietf.org<mailto:Txauth@ietf.org>
      https://www.ietf.org= /mailman/listinfo/txauth
      --
      Txauth mailing list
      Txauth@ietf.org<mailto:Txauth@ietf.org>
      https://www.ietf.org= /mailman/listinfo/txauth

      --
      TXAuth mailing list
      TXAuth@ietf.org<mailto:TXAuth@ietf.org>
      https://www.ietf.org= /mailman/listinfo/txauth
      --
      TXAuth mailing list
      TXAuth@ietf.org<mailto:TXAuth@ietf.org>
      https://www.ietf.org= /mailman/listinfo/txauth


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


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


      --000000000000acc35f05ad047ef8-- From nobody Sun Aug 16 13:39:41 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 1CC5F3A1122 for ; Sun, 16 Aug 2020 13:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 IyaiOCWRW4mG for ; Sun, 16 Aug 2020 13:39:34 -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 842CC3A1120 for ; Sun, 16 Aug 2020 13:39:33 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id t23so15266095ljc.3 for ; Sun, 16 Aug 2020 13:39:33 -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=aYeQKi3yF/RncOkOTT9Yyf2VhlYO4T79gR7w4nfjWhY=; b=cdK/wn6vMHeW1MSlmQ9HlfxA0Y0dkMFMPNhyoREAQnCcG4MsBRKIeqnsS+out+zyOj 1FiYbQaxhuAhOCiAcpfQ11fFtFxdA55Gw/FUMJoZJnH9/0C9ot00kv3f8Bv1vh+QipEN D/fgLPhqLrRrABrmDvvYTaLNiNp8bI+FmuX8VQ+m7gBPXiEbpRhu3p3rIiubieXj0q9w sq8GWaPfmMiBmL974erxnAWCw7BI/OjtrjQuVTLrk6y0wqGhEbL0FlCh/cWkARWG8QvI FI+KLM76jPFpYJNwiy5qKkWFZD+IN6A+hXLvKGys72DwD2GfpMZ3WRSnJbIaHYQXacEQ iQVQ== 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=aYeQKi3yF/RncOkOTT9Yyf2VhlYO4T79gR7w4nfjWhY=; b=dijKV2m7wWy3AAJRDhpxTl/V/T4k+UWQWc8LxzEmNDcad5ucOG0CUtItn3Kr5jPX+/ T0SJjj/3bnTxIFwNlNitK7beyExiP1FJw6I3IGaPLGjHaL8HAeNzBfn/CcXdj9RMIuGR 9ASzIWnsmrkVZr76XZtue5HERgQEHInRiyngsNZvBFUAOS6+a/ltAJ3CcPnxxiGvDo4a w5vxkGDAOnkvSwfhE/O2aYZ8P4K73dGnbRRdXIE8S2txxg754hitdDTSxBLZgTSES6/W HnQj/N0bY48xI9uAqHlWmJZZiFHSZJyoeme6DA+dvIjGfI5M0JSoe9kYYQwftHnn75L9 za/Q== X-Gm-Message-State: AOAM532JktKEdI5PBw+6N9L58fvrstUP0x81i3bxsbZT+NjLilw/7zzF KDaJdC8+4iCClIJ1Kh5ZEu+DMXh+c17Uwc/OXUo= X-Google-Smtp-Source: ABdhPJzk095iVLavpJ49Hraoc4F1RWAqKLABC1LPnIBV1NLhlXAVqESWlmsnwSjAhnrq1l/oQIpWSxApOjzeqDMG50c= X-Received: by 2002:a2e:7215:: with SMTP id n21mr6310029ljc.242.1597610371112; Sun, 16 Aug 2020 13:39:31 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> In-Reply-To: From: Dick Hardt Date: Sun, 16 Aug 2020 13:38:54 -0700 Message-ID: To: Fabien Imbault Cc: Justin Richer , Mike Jones , Tom Jones , Dave Tonge , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a8e4a805ad04a6fc" Archived-At: Subject: Re: [GNAP] Terminology 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: Sun, 16 Aug 2020 20:39:39 -0000 --000000000000a8e4a805ad04a6fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry Fabien, I had started this email and had not sent it. If we are successful, other ISO may build extensions on GNAP, just as OpenId Connect was built on top. Hopefully we will have created the right extension points so that it is straightforward. Here are some examples of other things that could be granted (I don't expect these to be worked on in this WG, or at least not anytime soon): - A grant of "digital money" from the Grant Server to the Grant Client. The GS is granting the funds to the GC with the User's authorization. This is not the same as authorizing a payment per the example in the wiki. - An assertion about the Grant Client made by the Grant Server, potentially with the User's authorization. This assertion could allow the GC to prove something about itself to a separate entity, or even a separate GS. /Dick On Wed, Aug 12, 2020 at 9:43 AM Fabien Imbault wrote: > Hi Dick, > > Maybe to make that discussion more concrete, what else do you imagine > could be exchanged (beyond resource & idclaims)? A few examples? > > Cheers > Fabien > > > > On Wed, Aug 12, 2020 at 6:40 PM Dick Hardt wrote: > >> What is being granted is whatever is being negotiated between the Grant >> Server and the Grant Client -> Which fits into the name of the WG, Grant >> Negotiation and Authorization Protocol, allows us to have names that are >> specific and precise for the roles (Grant Server and Grant Client rather >> than Requesting Party), and is usable by an extension that wants to >> negotiate some new thing between the two roles. >> >> I introduced the term "Grant" in XAuth to mean what the client requested= , >> and what the "server" provided, which included both resource access and >> identity claims. You are narrowly defining grant to ONLY mean "access to >> something". Sometimes I think you just want to disagree with me. :) >> >> I'd be interested in hearing from others! >> >> >> >> In the current drafts, that is resource access and identity claims. >> >> =E1=90=A7 >> >> On Wed, Aug 12, 2020 at 8:58 AM Justin Richer wrote: >> >>> What is being granted is access to something. This makes sense in terms >>> of rights bound to an access token, but I would argue it makes less sen= se >>> for things returned directly. >>> >>> Since you and I also disagree on whether returning things directly is a= n >>> important distinction (even though both the XAuth and XYZ proposals mak= e >>> this distinction), it doesn=E2=80=99t surprise me that you=E2=80=99d wa= nt to extend the >>> notion of =E2=80=9Cgrant=E2=80=9D to include anything and everything in= the request and >>> response. >>> >>> I am arguing for it being more specific and precise. >>> >>> =E2=80=94 Justin >>> >>> On Aug 11, 2020, at 6:08 PM, Dick Hardt wrote: >>> >>> A grant is whatever the client is asking from the server. Currently we >>> have access to resources and identity claims. It could contain anything >>> else an extension adds that a client may request from a server. >>> >>> Given the definition of grant that I included, why is grant not the >>> right term to use for this? >>> >>> >>> On Tue, Aug 11, 2020 at 1:35 PM Justin Richer wrote: >>> >>>> I did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said= that your >>>> definition of it was problematic. Namely, the desire to lump in claims >>>> about the user into the definition of the =E2=80=9Cgrant=E2=80=9D. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Aug 11, 2020, at 3:49 PM, Dick Hardt wrote: >>>> >>>> I agree that orchestrator may be a role in the protocol -- it is not a >>>> role in XYZ or XAuth today. >>>> >>>> Justin: would you explain why you think the term "grant" is >>>> problematic? It is in the WG name! >>>> >>>> The client is receiving more than access to resources from the GS, it >>>> is also receiving claims, so "client of the resource" is too limiting. >>>> >>>> Reading the definition of grant[1], it fits as a verb of what the GS i= s >>>> doing, and fits as a noun of what the GS provides to the client. >>>> >>>> A Grant Server is an Authorization Server in OAuth, and an OpenID >>>> Provider in OpenID Connect. >>>> The Grant Client is a Client in OAuth, and a Relying Party in OpenID >>>> Connect. >>>> >>>> Having new terms (GS and GC) in GNAP, separating the roles from OAuth >>>> and OpenID Connect. >>>> It is straightforward to know what a GC and GS do when you understand >>>> that a grant is a combination of resource access (from OAuth) and clai= ms >>>> (from OpenID Connect). >>>> >>>> /Dick >>>> >>>> [1] https://www.dictionary.com/browse/grant >>>> verb (used with object) >>>> to bestow or confer, especially by a formal act:to grant a charter. >>>> to give or accord:to grant permission. >>>> to agree or accede to:to grant a request. >>>> to admit or concede; accept for the sake of argument:I grant that >>>> point. >>>> SEE MORE >>>> noun >>>> something granted, as a privilege or right, a sum of money, or a tract >>>> of land:Several major foundations made large grants to fund the >>>> research project. >>>> the act of granting. >>>> >>>> >>>> [1] >>>> >>>> >>>> >>>> On Tue, Aug 11, 2020 at 12:31 PM Justin Richer wrote= : >>>> >>>>> I agree that =E2=80=9Corchestration=E2=80=9D is separate from what th= e classical >>>>> =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term =E2= =80=9Corchestrator=E2=80=9D fits with the >>>>> =E2=80=9Cuser agent=E2=80=9D concept that=E2=80=99s been brought up h= ere before, so I=E2=80=99m inclined to >>>>> believe it can be a separate role from the client. >>>>> >>>>> I personally think that =E2=80=9Cgrant client=E2=80=9D is confusing a= s it is not a >>>>> =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient of= the resource=E2=80=9D. >>>>> >>>>> I also think it=E2=80=99s problematic to lump in user claims with a = =E2=80=9Cgrant=E2=80=9D >>>>> and that=E2=80=99s just going to muddle everything. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Aug 11, 2020, at 3:25 PM, Dick Hardt wrote: >>>>> >>>>> I echo Mike's comments on preserving names when possible. The shift >>>>> from "consumer" in OAuth 1 to "client" in OAuth 2 was confusing to ma= ny. >>>>> >>>>> I also echo Tom's comments about separating Entities from Roles. >>>>> >>>>> Orchestration[1] in my opinion is not what the "client" is doing. >>>>> >>>>> Below is a stab at separating the entities and the roles >>>>> >>>>> /Dick >>>>> >>>>> *Tl;dr: * >>>>> - Client -> Grant Client >>>>> - added Relying Party, Claims Issuer, and Grant Server Operator as >>>>> entities >>>>> >>>>> *Roles* - parties to the protocol >>>>> Grant Client (GC), Grant Server (GS), Resource Server (RS) >>>>> >>>>> *Entities* - parties to a Trust Framework >>>>> User, Relying Party (RP), Claims Issuer (Issuer), Grant Server >>>>> Operator (GSO), Resource Owner (RO) >>>>> >>>>> *Grant *- may contain claims and/or access to resources >>>>> >>>>> *#Protocol Roles* >>>>> >>>>> *Grant Client* (GC) >>>>> - used by User >>>>> - operated / provided by RP >>>>> - requests Grants from the GS >>>>> - access resources at an RS >>>>> - consumes Claims >>>>> >>>>> *Grant Server* (GS) >>>>> - operated by GSO >>>>> - may interact with the User >>>>> - may interact with the RO >>>>> - accepts grant requests from GCs >>>>> - issues grants to GCs >>>>> - may issue claims >>>>> >>>>> *Resource Server* (RS) >>>>> - manages access to resources for the RO >>>>> - provides access to resources for the GC >>>>> - accepts access granted by the GS >>>>> >>>>> *#Legal Entities* >>>>> >>>>> *User* >>>>> - uses Grant Client >>>>> - may interact with the Grant Server >>>>> - may also be a RO >>>>> - trusts RP, Issuer, GSO >>>>> >>>>> *Relying Party* (RP) >>>>> - provides Grant Client to the User. >>>>> - may trust Issuers, GSOs, and ROs >>>>> >>>>> *Claims Issuer* (Issuer) >>>>> - issues claims to RP >>>>> - may use GS or RS to issue claims >>>>> >>>>> *Grant Server Operator* (GSO) >>>>> - operates the GS >>>>> - trusted by User, RP, and RO >>>>> - may also be an Issuer >>>>> >>>>> *Resource Owne*r (RO) >>>>> - owns resources at the RS >>>>> - trusts GSO to control access to the resources >>>>> - may be same entity as the User >>>>> - may also be an Issuer >>>>> >>>>> [1] https://en.wikipedia.org/wiki/Orchestration_(computing) >>>>> >>>>> Orchestration (computing) >>>>> From Wikipedia, the free encyclopedia >>>>> Jump to navigation >>>>> Jump >>>>> to search >>>>> >>>>> In system administration >>>>> , *orchestration= * is >>>>> the automated configuration >>>>> , >>>>> coordination, and management of computer systems and software >>>>> .[1] >>>>> >>>>> A number of tools exist >>>>> for >>>>> automation of server configuration and management, including Ansible >>>>> , Puppet >>>>> , Salt >>>>> , Terraform >>>>> ,[2] >>>>> >>>>> and AWS CloudFormation >>>>> .[3] >>>>> >>>>> Usage[edit >>>>> >>>>> ] >>>>> Orchestration is often discussed in the context of service-oriented >>>>> architecture >>>>> , >>>>> virtualization >>>>> , provisioning , converge= d >>>>> infrastructure >>>>> and dynamic >>>>> datacenter topics. >>>>> Orchestration in this sense is about aligning the business request wi= th the >>>>> applications, data, and infrastructure.[4] >>>>> >>>>> In the context of cloud computing >>>>> , the main difference >>>>> between workflow automation >>>>> and orchestration >>>>> is that workflows are processed and completed as processes within a s= ingle >>>>> domain for automation purposes, whereas orchestration includes a work= flow >>>>> and provides a directed action towards larger goals and objectives.[1= ] >>>>> >>>>> In this context, and with the overall aim to achieve specific goals >>>>> and objectives (described through quality of service >>>>> parameters), for >>>>> example, meet application performance goals using minimized cost[5] >>>>> and >>>>> maximize application performance within budget constraints.[6] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 11, 2020 at 9:33 AM Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> >>>>>> One of the things that people hated about OAuth was it invented new >>>>>> terminology that wasn=E2=80=99t in common use. But for better or fo= r worse, the >>>>>> terms Client, Authorization Server, and Protected Resource are now w= idely >>>>>> understood. >>>>>> >>>>>> >>>>>> >>>>>> Let=E2=80=99s not make people similarly hate GNAP by inventing even = more >>>>>> novel terms, when existing terms will fit the bill. Client wasn=E2= =80=99t a >>>>>> perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to the voca= bulary menagerie would >>>>>> definitely make things worse. >>>>>> >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> >>>>>> *From:* TXAuth *On Behalf Of *Tom Jones >>>>>> *Sent:* Tuesday, August 11, 2020 8:44 AM >>>>>> *To:* Dave Tonge >>>>>> *Cc:* Francis Pouatcha ; Justin Richer < >>>>>> jricher@mit.edu>; Dick Hardt ; Benjamin Kaduk = < >>>>>> kaduk@mit.edu>; Fabien Imbault ; Denis < >>>>>> denis.ietf@free.fr>; txauth@ietf.org >>>>>> *Subject:* Re: [GNAP] Terminology >>>>>> >>>>>> >>>>>> >>>>>> the term "orchestator" does not match any use case i have. >>>>>> >>>>>> Let's be clear that there are four entities to a single transaction >>>>>> in the real world sense of things. (and others that support the >>>>>> transaction.) >>>>>> >>>>>> Then we can focus on the end point roles. I will focus on the data >>>>>> privacy issues, API's have the same parties with different terminolo= gy. >>>>>> >>>>>> 1. the subject of the data to be transferred. >>>>>> >>>>>> 2. the user of a grant from the subject to act as delegate. (see >>>>>> https://wiki.idesg.org/wiki/index.php/Delegation for how to enable >>>>>> the user) >>>>>> >>>>>> 3. the site that has a repository of user data with legal obligation= s >>>>>> to protect that data (the GDPR) (role resource server.) >>>>>> >>>>>> 4 the site that wants either access to the data, or some privacy >>>>>> preserving statement about the existence and content of the data. (r= ole of >>>>>> client, vendor, PISP, etc.) >>>>>> >>>>>> 5. some sorts of facilitator sites for allowing access (roles like >>>>>> authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have be= en left >>>>>> out of OAUTH for good reason. >>>>>> >>>>>> >>>>>> >>>>>> This is a note supporting the separation of roles from legal >>>>>> entities. BTW, I firmly believe that the legal entity also needs to= be >>>>>> ID'd by the transaction. >>>>>> >>>>>> Peace ..tom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge >>>>>> wrote: >>>>>> >>>>>> Hi all >>>>>> >>>>>> >>>>>> >>>>>> I agree that "client" can be confusing. I would be in support of >>>>>> alternative terminology. >>>>>> >>>>>> We can always have some wording that explains that an "Orchestrator" >>>>>> in GNAP plays a similar role to "Client" in OAuth. >>>>>> >>>>>> >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> On Tue, 11 Aug 2020 at 07:52, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Hi Francis, >>>>>> >>>>>> >>>>>> >>>>>> I like your proposal, seems much more intuitive. >>>>>> >>>>>> >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> >>>>>> Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis Pouatcha a >>>>>> =C3=A9crit : >>>>>> >>>>>> Hello Denis, Justin, Dick, Fabien, >>>>>> >>>>>> >>>>>> >>>>>> In this post ( >>>>>> https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-J= OGNw/) >>>>>> i suggested we use the word "Orchestrator" to designate the piece of >>>>>> software that orchestrate interaction between "Requestor" (a.k.a. Us= er), AS >>>>>> and RS to obtain the protected resource. >>>>>> >>>>>> >>>>>> >>>>>> We are turning around the same topic. As soon as we go beyond the >>>>>> original oAuth protocol, the word 'Client' becomes confusing. >>>>>> >>>>>> >>>>>> >>>>>> In the same response, I suggest we talk about "roles" and not >>>>>> "entities". >>>>>> >>>>>> >>>>>> >>>>>> Best regards. >>>>>> >>>>>> /Francis >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>> I still think that client was the right name in OAuth 2, as the >>>>>> client wanted to do a client-server interaction, so the client used = OAuth 2 >>>>>> to get an access token to interact with the "server". >>>>>> >>>>>> >>>>>> >>>>>> I do agree that it is not the best term in GNAP. Primarily because >>>>>> GNAP is a combination of the client from OAuth 2, and the relying pa= rty >>>>>> from OIDC. >>>>>> >>>>>> >>>>>> >>>>>> /Dick >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 12:50 PM Justin Richer >>>>>> wrote: >>>>>> >>>>>> On Aug 6, 2020, at 12:53 PM, Dick Hardt wrote= : >>>>>> >>>>>> >>>>>> >>>>>> The term client in OAuth came from the computer science definition o= f >>>>>> client-server interaction. >>>>>> >>>>>> >>>>>> >>>>>> This, I would argue, is exactly why it=E2=80=99s a bad label for som= ething >>>>>> that=E2=80=99s distinctly more specific in this context, and I would= love to see >>>>>> GNAP adopt a more specific label for the role that we traditionally = called >>>>>> =E2=80=9Cclient=E2=80=9D in OAuth. >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The client is getting an access token so it can call a server, >>>>>> specifically, a resource server (to differentiate it from the author= ization >>>>>> server). >>>>>> >>>>>> >>>>>> >>>>>> The confusion in my experience usually stems from people working wit= h >>>>>> software that is acting in multiple roles. IE, the software that is = acting >>>>>> as a client in once context, is also acting as an RS in other contex= ts, or >>>>>> even acting as an AS. The other confusion is that people view client= s as >>>>>> being the software the user is using -- although it may not be actin= g as a >>>>>> client in the oauth context. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> To me, client has always been a strange word in the context of OAuth= , >>>>>> as it has a meaning well defined both in everyday life (this client = is a >>>>>> good customer) and in computer science (client-server interaction). = Thus I >>>>>> always have to make the mental translation to the OAuth world before= any >>>>>> discussion... And any teaching experience shows that it does make th= e >>>>>> concepts hard to grasp for a majority of (clever) people. >>>>>> >>>>>> >>>>>> >>>>>> As for the RO, previous discussions suggested Resource >>>>>> Controller (RC) also, which may be a bit more specific than manager. >>>>>> >>>>>> >>>>>> >>>>>> Fabien >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 6, 2020 at 1:00 PM Denis wrote: >>>>>> >>>>>> Justin and Dick, >>>>>> >>>>>> >>>>>> >>>>>> [Was: "Revisiting the photo sharing example (a driving use case for >>>>>> the creation of OAuth)"] >>>>>> >>>>>> >>>>>> >>>>>> So let us attempt to define new terms: >>>>>> >>>>>> *initiating application (IA)*: application by means of which a user >>>>>> initiates interactions with RS(s) and AS(s) >>>>>> >>>>>> In the same way, we should get rid of the term Resource Owner (RO), >>>>>> which is currently defined as: >>>>>> >>>>>> Resource Owner (RO): entity capable of granting access to a protecte= d >>>>>> resource >>>>>> >>>>>> I propose to replace it with Resource Manager (RM): >>>>>> >>>>>> *Resource Manager (RM)* : application or user that manages an access >>>>>> decision function of a Resource Server >>>>>> >>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> I agree with Justin. Redefining well used terms will lead to >>>>>> significant confusion. If we have a different role than what we have= had >>>>>> in the past, then that role should have a name not being used alread= y in >>>>>> OAuth or OIDC. >>>>>> >>>>>> >>>>>> >>>>>> Given what we have learned, and my own experience explaining what a >>>>>> Client is, and is not, improving the definition for Client could pro= ve >>>>>> useful. I am not suggesting the term be redefined, but clarified. >>>>>> >>>>>> >>>>>> >>>>>> For example, clarifying that a Client is a role an entity plays in >>>>>> the protocol, and that the same entity may play other roles at other= times, >>>>>> or some other language to help differentiate between "role" and "ent= ity". >>>>>> >>>>>> >>>>>> >>>>>> /Dick >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer wrote= : >>>>>> >>>>>> I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a b= etter fit, but >>>>>> I=E2=80=99m not really in favor of taking an existing term and apply= ing a >>>>>> completely new definition to it. In other words, I would sooner stop= using >>>>>> =E2=80=9Cclient=E2=80=9D and come up with a new, more specific and a= ccurate term for the >>>>>> role than to define =E2=80=9Cclient=E2=80=9D as meaning something co= mpletely different. We >>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the >>>>>> even-more-confusing =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2= =80=9D, but OAuth 2 doesn=E2=80=99t use the >>>>>> term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cser= ver=E2=80=9D on its own but instead >>>>>> always qualifies it with =E2=80=9CAuthorization Server=E2=80=9D and = =E2=80=9CResource Server=E2=80=9D. >>>>>> >>>>>> >>>>>> >>>>>> GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is >>>>>> ignore the fact that GNAP is going to be coming up in a world that i= s >>>>>> already permeated by OAuth 2 and its terminology. We don=E2=80=99t = have a blank >>>>>> slate to work with, but neither are we bound to use the same terms a= nd >>>>>> constructs as before. It=E2=80=99s going to be a delicate balance! >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> >>>>>> On Aug 4, 2020, at 3:32 PM, Warren Parad wrote: >>>>>> >>>>>> >>>>>> >>>>>> I think that is fundamentally part of the question: >>>>>> >>>>>> We are clear that we are producing a protocol that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusin= g >>>>>> terms >>>>>> from OAuth 2.0 but with different definitions may lead to unnecessar= y >>>>>> confusion >>>>>> >>>>>> >>>>>> >>>>>> If we say that this document assumes OAuth2.0 terminology, then we >>>>>> should not change the meanings of any definition. If we are saying t= his >>>>>> supersedes or replaces what OAuth 2.0 creates, then we should pick t= he best >>>>>> word for the job and ignore conflicting meanings from OAuth 2.0. I h= ave a >>>>>> lot of first hand experience of industries "ruining words", and atte= mpting >>>>>> to side-step the problem rather than redefining the word just confus= es >>>>>> everyone as everyone forgets the original meaning as new documents c= ome >>>>>> out, but the confusion with the use of a non-obvious word continues. >>>>>> >>>>>> >>>>>> >>>>>> Food for thought. >>>>>> >>>>>> - Warren >>>>>> >>>>>> >>>>>> *Warren Parad* >>>>>> >>>>>> Founder, CTO >>>>>> >>>>>> Secure your user data and complete your authorization architecture. >>>>>> Implement Authress . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk wrote: >>>>>> >>>>>> Hi Denis, >>>>>> >>>>>> On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote: >>>>>> > Hi Justin, >>>>>> > >>>>>> > Since you replied in parallel, I will make a response similar to >>>>>> the one >>>>>> > I sent to Dick. >>>>>> > >>>>>> > > Hi Denis, >>>>>> > > >>>>>> > > I think there=E2=80=99s still a problem with the terminology in = use here. >>>>>> What >>>>>> > > you describe as RS2, which might in fact be an RS unto itself, i= s >>>>>> a >>>>>> > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clie= nt of RS1/. What >>>>>> you >>>>>> > > call a =E2=80=9Cclient=E2=80=9D has no analogue in the OAuth wor= ld, but it is not >>>>>> at >>>>>> > > all the same as an OAuth client. I appreciate your mapping of th= e >>>>>> > > entities below, but it makes it difficult to hold a discussion i= f >>>>>> we >>>>>> > > aren=E2=80=99t using the same terms. >>>>>> > > >>>>>> > > The good news is that this isn=E2=80=99t OAuth, and as a new WG = we can >>>>>> define >>>>>> > > our own terms. The bad news is that this is really hard to do. >>>>>> > > >>>>>> > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with ne= w >>>>>> definitions, >>>>>> > > but we=E2=80=99ve got a chance to be more precise with how we de= fine >>>>>> things. >>>>>> > >>>>>> > In the ISO context, each document must define its own terminology. >>>>>> The >>>>>> > boiler plate for RFCs does not mandate a terminology or definition= s >>>>>> section >>>>>> > but does not prevent it either. The vocabulary is limited and as >>>>>> long as >>>>>> > we clearly define what our terms are meaning, we can re-use a term >>>>>> already >>>>>> > used in another RFC. This is also the ISO approach. >>>>>> >>>>>> Just because we can do something does not necessarily mean that it i= s >>>>>> a >>>>>> good idea to do so. We are clear that we are producing a protocol >>>>>> that is >>>>>> conceptually (if not more strongly) related to OAuth 2.0, and reusin= g >>>>>> terms >>>>>> from OAuth 2.0 but with different definitions may lead to unnecessar= y >>>>>> confusion. If I understand correctly, a similar reasoning prompted >>>>>> Dick to >>>>>> use the term "GS" in XAuth, picking a name that was not already used >>>>>> in >>>>>> OAuth 2.0. >>>>>> >>>>>> -Ben >>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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/ >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at https://register.fca.org= .uk/ >>>>>> . Moneyhub Financial Technology is reg= istered >>>>>> in England & Wales, company registration number 06909772. Moneyhub >>>>>> Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus = Building, >>>>>> Temple Quay, 1 Friary, Bristol, BS1 6EA. * >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>>> >>>>> >>>> >>> --000000000000a8e4a805ad04a6fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Sorry Fabien, I had started this email an= d had not sent it.

      If we are successful, other ISO may b= uild extensions on GNAP, just as OpenId Connect was built on top. Hopefully= we will have created the right extension points so that it is straightforw= ard. Here are some examples of other things that could be granted (I don= 9;t expect these to be worked on in this WG, or at least not anytime soon):=

      - A grant of "digital money" from = the Grant Server to the Grant Client. The GS is granting the funds to the G= C with the User's authorization. This is not the same as authorizing a = payment per the example in the wiki.

      - An as= sertion about the Grant Client made by the Grant Server, potentially with t= he User's authorization. This assertion could allow the GC to prove som= ething about itself to a separate entity, or even a separate GS.
      =
      /Dick


      On Wed, Aug 12, 2020 at 9:43 AM Fa= bien Imbault <fabien.imbault= @gmail.com> wrote:
      Hi Dick,=C2=A0

      Maybe to make= that discussion more concrete, what else do you imagine could be exchanged= (beyond resource & idclaims)? A few examples?

      Cheers
      Fabien=C2=A0


      On Wed, A= ug 12, 2020 at 6:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
      What is being gra= nted is whatever is being negotiated between the Grant Server and the Grant= Client -> Which fits into the name of the WG, Grant Negotiation and Aut= horization Protocol, allows us to have names that are specific and precise = for the roles (Grant Server and Grant Client rather than Requesting Party),= and is usable by an extension that wants to negotiate some new thing betwe= en the two roles.=C2=A0

      I introduced the term "Gran= t" in XAuth to mean what the client requested, and what the "serv= er" provided, which included both resource access and identity claims.= You are narrowly defining grant to ONLY mean "access to something&quo= t;. Sometimes I think you just want to disagree with me. :)

      <= /div>
      I'd be interested in hearing from others!



      In the current drafts, = that is resource access and identity claims.=C2=A0

      3D==E1=90=A7

      On Wed, Aug 12, 2020 at 8:58 AM Jus= tin Richer <jricher= @mit.edu> wrote:
      What is being granted is access to something. This makes sense= in terms of rights bound to an access token, but I would argue it makes le= ss sense for things returned directly.

      Since you and I a= lso disagree on whether returning things directly is an important distincti= on (even though both the XAuth and XYZ proposals make this distinction), it= doesn=E2=80=99t surprise me that you=E2=80=99d want to extend the notion o= f =E2=80=9Cgrant=E2=80=9D to include anything and everything in the request= and response.=C2=A0

      I am arguing for it being mor= e specific and precise.

      =C2=A0=E2=80=94 Justin
      =

      On Aug 11, 2020, at 6:08 PM, Dick H= ardt <dick.har= dt@gmail.com> wrote:

      A grant is whate= ver the client is asking from the server. Currently we have access to resou= rces and identity claims. It could contain anything else an extension adds = that a client may request from a server.

      Given the defin= ition of grant that I included, why is grant not the right term to use for = this?


      On Tue, Aug 11, 2020 at 1:35 PM Justin Richer <= ;jricher@mit.edu&g= t; wrote:
      I= did not say the term =E2=80=9Cgrant=E2=80=9D was problematic, I said that = your definition of it was problematic. Namely, the desire to lump in claims= about the user into the definition of the =E2=80=9Cgrant=E2=80=9D.=C2=A0
      =C2=A0=E2=80=94 Justin

      On Aug 11, 2020, at 3:49 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
      I agree that orchestrator may be a role in the = protocol -- it is not a role in XYZ or XAuth today.

      Just= in: would you explain why you think the term "grant" is problemat= ic? It is in the WG name!

      The client is receiving= =C2=A0more than access to resources from the GS, it is also receiving=C2=A0= claims, so "client of the resource" is too limiting.
      Reading the definition of grant[1], it fits as a verb of what = the GS is doing, and fits as a noun of what the GS provides to the client.<= /div>

      A Grant Server is an Authorization Server in OAuth= , and an OpenID Provider in OpenID Connect.
      The Grant Client is a= Client in OAuth, and a Relying Party in OpenID Connect.

      Having new terms (GS and GC) in GNAP, separating the roles from OAut= h and OpenID Connect.
      It is straightforward=C2=A0to know what a G= C and GS do when you understand that=C2=A0a grant is a combination of resou= rce access (from OAuth) and claims (from OpenID Connect).

      /Dick

      verb (used with object)

      to bestow or confer, especially by a = formal act:to grant a charter.<= /div>
      to give or accord:to grant permission.
      to agree or accede to:to grant = a request.
      to admit or concede; accept for the sake of arg= ument:I grant that point.
      =
      =

      noun
      somethi= ng granted, as a privilege or right, a sum of money, or a tract of land:Several major foundations made large grants to f= und the research project.
      the act of granting.



      [1]=C2=A0
      =



      On Tue, Aug 11, 2020 at 12:31 PM Justin Riche= r <jricher@mit.edu<= /a>> wrote:
      <= div>I agree that =E2=80=9Corchestration=E2=80=9D is separate from what the = classical =E2=80=9Cclient=E2=80=9D in OAuth is doing =E2=80=94 but the term= =E2=80=9Corchestrator=E2=80=9D fits with the =E2=80=9Cuser agent=E2=80=9D = concept that=E2=80=99s been brought up here before, so I=E2=80=99m inclined= to believe it can be a separate role from the client.

      I= personally think that =E2=80=9Cgrant client=E2=80=9D is confusing as it is= not a =E2=80=9Cclient of the grant=E2=80=9D but rather a =E2=80=9Cclient o= f the resource=E2=80=9D.

      I also think it=E2=80=99s= problematic to lump in user claims with a =E2=80=9Cgrant=E2=80=9D and that= =E2=80=99s just going to muddle everything.=C2=A0

      = =C2=A0=E2=80=94 Justin


      I echo Mike'= s comments on preserving names when possible. The shift from "consumer= " in OAuth 1 to "client" in OAuth 2 was confusing to many.

      I also echo Tom's comments about separating= Entities from Roles.

      Orchestration[1] in my opini= on is not what the "client" is doing.

      Be= low is a stab at separating the entities and the roles

      =
      /Dick

      Tl;dr:=C2=A0
      - Client= =C2=A0-> Grant Client
      - added Relying Party, Claims Issuer, an= d Grant Server Operator as entities

      Roles<= /b> - parties to the protocol
      Grant Client (GC), Grant Server (GS= ), Resource Server (RS)

      Entiti= es - parties to a Trust Framework
      User, Relying Party (RP), Claims = Issuer (Issuer), Grant Server Operator (GSO), Resource=C2=A0Owner (RO)

      Grant -=C2=A0may contain claim= s and/or access to resources

      #Protocol Roles

      Grant Client (GC)
      - used by Use= r
      - operated / provided by RP
      - requests Grants from th= e GS
      - access resources at an RS
      - consumes Claims

      Grant Server (GS)
      - operated by GSO
      - may interact with the User=C2=A0
      - may interact with t= he RO
      - accepts grant requests from GCs
      - issues grants= to GCs
      - may issue claims

      Resource = Server (RS)
      - manages access to resources for the RO
      - provides access to resources for the GC
      - accepts access gran= ted by the GS

      #Legal Entities
      User
      - uses Grant Client
      - may inter= act with the Grant Server
      - may also be a RO
      - trusts R= P, Issuer, GSO

      Relying Party (RP)
      - provides Grant Client to the User.
      - may trust Issuers, GSOs,= and ROs

      Claims Issuer (Issuer)
      -= issues claims to RP
      - may use GS or RS to issue claims

      Grant Server Operator (GSO)
      - operates the= GS
      - trusted by User, RP, and RO
      - may also be an Issu= er

      Resource Owner (RO)
      - o= wns resources at the RS
      - trusts GSO to control access to the res= ources
      - may be same entity as the User
      - may also= be an Issuer


      =

      Orchestration (computing)

      From Wikipedia, the free encyclopedia<= /div>
      Jump to= navigationJump to search
      In=C2=A0system administration<= /a>,=C2=A0orchestration=C2=A0is the automated=C2=A0configuration, coordination, and management of= computer systems and=C2=A0software.[1]
      A=C2=A0number of tools exist=C2=A0for automation of server configu= ration and management, including=C2=A0Ansible= ,=C2=A0Puppet,=C2=A0Salt,=C2=A0Terraform,[2]=C2=A0and=C2=A0AWS CloudFormation.[3]

      = Usage[edit]

      Orches= tration is often discussed in the context of=C2=A0service-oriented architecture,=C2=A0virtualization,=C2=A0provisioning,=C2=A0converged= infrastructure=C2=A0and dynamic=C2=A0datacenter=C2= =A0topics. Orchestration in this sense is about aligning the business reque= st with the applications, data, and infrastructure.<= a href=3D"https://en.wikipedia.org/wiki/Orchestration_(computing)#cite_note= -4" style=3D"text-decoration-line:none;color:rgb(11,0,128);background:none"= target=3D"_blank">[4]
      In this context, and with the ov= erall aim to achieve specific goals and objectives (described through=C2=A0= quality of service=C2=A0parameters), for = example, meet application performance goals using minimized cost[5]= =C2=A0and maximize application performance within budget constraints.[6]<= /a>

      =






      On Tue, Aug = 11, 2020 at 9:33 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

      One of the t= hings that people hated about OAuth was it invented new terminology that wa= sn=E2=80=99t in common use.=C2=A0 But for better or for worse, the terms Cl= ient, Authorization Server, and Protected Resource are now widely understood.

      =C2=A0

      Let=E2=80=99s not make people simi= larly hate GNAP by inventing even more novel terms, when existing terms wil= l fit the bill.=C2=A0 Client wasn=E2=80=99t a perfect choice but adding =E2= =80=9COrchestrator=E2=80=9D to the vocabulary menagerie would definitely make things worse.

      =C2=A0

      =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

      =C2=A0

      = From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Tom Jones
      Sent: Tuesday, August 11, 2020 8:44 AM
      To: Dave Tonge <dave.tonge@moneyhub.com>
      Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <jricher@mit.edu>; Dick Hardt <dick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>; Fabien Imbault <fabien.imbault@gmail.com>; Denis <= denis.ietf@free.fr<= /a>>; txauth@ietf.o= rg
      Subject: Re: [GNAP] Terminology

      =C2=A0

      the term "orchestator" does not match= any use case i have.

      Let's be clear that there are four entities= to a single transaction in the real world sense of things. (and others tha= t support the=C2=A0 transaction.)

      Then we can focus on the end point roles. I wil= l focus on the data privacy issues, API's have the same parties with di= fferent terminology.

      1. the subject of the data to be transferred.

      2. the user of a grant from the subject to act = as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable = the user)

      3. the site that has a repository of user data = with legal obligations to protect that data (the GDPR) (role resource serve= r.)

      4 the site that wants either access to the data= , or some privacy preserving statement about the existence and content of t= he data. (role of client, vendor, PISP, etc.)

      5. some sorts of facilitator sites for allowing= access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) = these have been left out of OAUTH for good reason.

      =C2=A0

      This is a note supporting the separation of rol= es from legal entities.=C2=A0 BTW, I firmly believe that the legal entity a= lso needs to be ID'd by the transaction.

      Peace ..tom

      =C2=A0

      =C2=A0

      On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

      Hi all

      =C2=A0

      I agree that "client" can be confusing. I would = be in support of alternative terminology.

      We can always have some wording that explains that an &quo= t;Orchestrator" in GNAP plays a similar role to "Client" in = OAuth.

      =C2=A0

      Dave

      =C2=A0

      On Tue, 11 Aug 2020 at 07:52, Fabien Imbault &l= t;fabien.imba= ult@gmail.com> wrote:

      Hi Francis,

      =C2=A0

      I like your proposal, seems much more intuitive= .=C2=A0

      =C2=A0

      Fabien=C2=A0

      =C2=A0

      Le mar. 11 ao=C3=BBt 2020 =C3=A0 04:17, Francis= Pouatcha <fpo@adors= ys.de> a =C3=A9crit=C2=A0:

      Hello Denis, Justin, Dick, Fabien,

      =C2=A0

      In this post (http= s://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/) = i suggested we use the word "Orchestrator" to designate the piece of software that orchestrate interaction between &q= uot;Requestor" (a.k.a. User), AS and RS to obtain the protected resour= ce.=C2=A0

      =C2=A0

      We are turning around the same topic. As soon a= s we go beyond=C2=A0the original oAuth protocol, the word 'Client' = becomes confusing.

      =C2=A0

      In the same response, I suggest=C2=A0we talk ab= out "roles" and not "entities".

      =C2=A0

      Best regards.

      /Francis

      =C2=A0

      On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:

      I still think that client was the right name in= OAuth 2, as the client wanted to do a client-server interaction, so the cl= ient used OAuth 2 to get an access token to interact with the "server&= quot;.

      =C2=A0

      I do agree that it is not the best term in GNAP= . Primarily because GNAP is a combination of the client from OAuth 2, and t= he relying party from OIDC.=C2=A0

      =C2=A0

      /Dick

      =E1=90=A7

      =C2=A0

      On Thu, Aug 6, 2020 at 12:50 PM Justin Richer &= lt;jricher@mit.edu= > wrote:

      On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

      =C2=A0

      The term client in OAuth came from the computer= science definition of client-server interaction.

      =C2=A0

      This, I would argue, is exactly why it=E2=80=99= s a bad label for something that=E2=80=99s distinctly more specific in this= context, and I would love to see GNAP adopt a more specific label for the = role that we traditionally called =E2=80=9Cclient=E2=80=9D in OAuth.=

      =C2=A0

      =C2=A0=E2=80=94 Justin



      =C2=A0

      The client is getting an access token so it can= call a server, specifically, a resource server (to differentiate it from t= he authorization server).

      =C2=A0

      The confusion in my experience usually stems fr= om people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0r= oles. IE, the software=C2=A0that is acting as a client in once context, is = also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software = the user is using -- although it may not be acting as a client in the oauth= context.

      =C2=A0

      =C2=A0

      =C2=A0

      =E1=90=A7

      =C2=A0

      On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault &= lt;fabien.imb= ault@gmail.com> wrote:

      Hi,=C2=A0

      =C2=A0

      To me, client has always been a strange word in= the context of OAuth, as it has a meaning well defined both in everyday li= fe (this client is a good customer) and in computer science (client-server = interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any= teaching experience shows that it does make the concepts hard to grasp for= a majority of (clever) people.

      =C2=A0

      As for the RO, previous discussions suggested R= esource Controller=C2=A0(RC)=C2=A0also, which may be a bit more specific th= an manager.=C2=A0

      =C2=A0

      Fabien=C2=A0

      =C2=A0

      On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr>= ; wrote:

      Ju= stin and Dick,

      =C2=A0

      [W= as:=C2=A0 "Revisiting the photo sharing example (a driving use case fo= r the creation of OAuth)"]

      =C2=A0

      So= let us attempt to define new terms:

      initiating application (IA): application by means of which a user initiates interactions with= RS(s) and AS(s)

      In= the same way, we should get rid of the term Resource Owner (RO), which is = currently defined as:

      Re= source Owner (RO): entity capable of granting access to a protected resourc= e

      I = propose to replace it with Resource Manager (RM):

      Resource Manager (RM) : application or user= that manages an access decision function of a Resource Server

      D= enis

      =C2=A0

      I agree with Justin. Redefining well used terms= will lead to significant confusion. If we have a different role than what = we have had in=C2=A0the past, then that role should have a name not being u= sed already in OAuth or OIDC.

      =C2=A0

      Given what we have learned, and my own experien= ce explaining what a Client is, and is not, improving the definition for Cl= ient could prove useful. I am not suggesting the term be redefined, but cla= rified.=C2=A0

      =C2=A0

      For example, clarifying that a Client is a role= an entity plays in the protocol, and that the same entity may play other r= oles at other times, or some other language to help differentiate between &= quot;role" and "entity".

      =C2=A0

      /Dick

      =E1=90=A7

      =C2=A0

      On Wed, Aug 5, 2020 at 8:20 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:

      I=E2=80=99m in favor of coming up with a new te= rm that=E2=80=99s a better fit, but I=E2=80=99m not really in favor of taki= ng an existing term and applying a completely new definition to it. In othe= r words, I would sooner stop using =E2=80=9Cclient=E2=80=9D and come up wit= h a new, more specific and accurate term for the role than to define =E2=80=9C= client=E2=80=9D as meaning something completely different. We did this in g= oing from OAuth 1 to OAuth 2 already, moving from the even-more-confusing = =E2=80=9Cconsumer=E2=80=9D to =E2=80=9Cclient=E2=80=9D, but OAuth 2 doesn= =E2=80=99t use the term =E2=80=9Cconsumer=E2=80=9D at all, nor does it use =E2=80=9Cserver=E2= =80=9D on its own but instead always qualifies it with =E2=80=9CAuthorizati= on Server=E2=80=9D and =E2=80=9CResource Server=E2=80=9D.

      =C2=A0

      GNAP can do something similar, in my opinion. B= ut what we can=E2=80=99t do is ignore the fact that GNAP is going to be com= ing up in a world that is already permeated =C2=A0by OAuth 2 and its termin= ology. We don=E2=80=99t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2= =80=99s going to be a delicate balance!

      =C2=A0

      =C2=A0=E2=80=94 Justin



      On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch>= ; wrote:

      =C2=A0

      I think that is fundamentally part of the quest= ion:

      We are clear that we are prod= ucing a protocol that is
      conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
      from OAuth 2.0 but with different definitions may lead to unnecessary
      confusion

      =C2=A0

      If we say that this document assumes OAuth2.0 t= erminology, then we should not change the meanings of any definition. If we= are saying this supersedes or replaces what OAuth 2.0 creates, then we sho= uld pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand exp= erience of industries "ruining words", and attempting to side-ste= p the problem rather than redefining the word just confuses everyone as eve= ryone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word c= ontinues.

      =C2=A0

      Food for thought.

      - Warren

      Warren Parad<= u>

      Founder, CTO=

      Secure your u= ser data and complete your authorization architecture. Implement=C2=A0Authress.

      =C2=A0

      =C2=A0

      On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:

      Hi Denis,

      On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
      > Hi Justin,
      >
      > Since you replied in parallel, I will make a response similar to the o= ne
      > I sent to Dick.
      >
      > > Hi Denis,
      > >
      > > I think there=E2=80=99s still a problem with the terminology in u= se here. What
      > > you describe as RS2, which might in fact be an RS unto itself, is= a
      > > =E2=80=9CClient=E2=80=9D in OAuth parlance because it is /a clien= t of RS1/. What you
      > > call a=C2=A0=E2=80=9Cclient=E2=80=9D has no analogue in the OAuth= world, but it is not at
      > > all the same as an OAuth client. I appreciate your mapping of the=
      > > entities below, but it makes it difficult to hold a discussion if= we
      > > aren=E2=80=99t using the same terms.
      > >
      > > The good news is that this isn=E2=80=99t OAuth, and as a new WG w= e can define
      > > our own terms. The bad news is that this is really hard to do. > >
      > > In GNAP, we shouldn=E2=80=99t just re-use existing terms with new= definitions,
      > > but we=E2=80=99ve got a chance to be more precise with how we def= ine things.
      >
      > In the ISO context, each document must define its own terminology. The=
      > boiler plate for RFCs does not mandate a terminology or definitions se= ction
      > but does not prevent it either. The vocabulary is limited and as long = as
      > we clearly define what our terms are meaning, we can re-use a term alr= eady
      > used in another RFC. This is also the ISO approach.

      Just because we can do something does not necessarily mean that it is a
      good idea to do so.=C2=A0 We are clear that we are producing a protocol tha= t is
      conceptually (if not more strongly) related to OAuth 2.0, and reusing terms=
      from OAuth 2.0 but with different definitions may lead to unnecessary
      confusion.=C2=A0 If I understand correctly, a similar reasoning prompted Di= ck to
      use the term "GS" in XAuth, picking a name that was not already u= sed in
      OAuth 2.0.

      -Ben

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

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

      =C2=A0

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

      =C2=A0

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

      =C2=A0

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


      =C2=A0

      --

      Francis Pouatcha

      Co-Founder and Technical Lead

      adorsys GmbH & Co. KG

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

      =C2=A0

      =C2=A0

      Moneyhub Enterprise= is a trading style of Moneyhub Financial Technology Limited which is autho= rised and regulated by the Financial Conduct Authority ("FCA"). M= oneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building= , Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

      DISCLAIMER: This email (including any attachments) is subject to copyrigh= t, and the information in it is confidential. Use of this email or of any i= nformation in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's s= ole responsibility to scan all attachments for viruses. All calls and email= s to and from this company may be monitored and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.


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




      On Tue, Aug 11, 2020 at 7:25 PM Denis <denis.ietf@free.fr> wrote:
      =20 =20 =20
      To all,

      We are circling around. In order to progress about the terminology, I propose the following:

      1=C2=B0 Adopt the ISO rule for a definition:
      The definition shall be written in such a form that it can replace the term in its context. <= br> It shall not start with an article (=E2=80=9C= the=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with a full stop.
      A definition shall not take the form of, or contain, a requirement.
      2=C2=B0 Propose <= font face=3D"Arial">at the same time a term AND its definition.

      3=C2=B0 If you don't like a term or its definition proposed by someone else, this is fine ... but only as long as
      you have a counter proposal for either the term and/or its definition.       As an example, only stating that
      " "client" can be confusing" would not be a v= alid proposal.

      Terms and definitions are used in the context of RFCs issued by a WG and it is fine using terms
      already used by other       RFCs issued by another WG as long as we clearly define them.

      Denis

      =20 =20 =20 =20

      One of th= e things that people hated about OAuth was it invented new terminology that wasn=E2=80=99t in common use.=C2=A0 But for be= tter or for worse, the terms Client, Authorization Server, and Protected Resource are now widely understood.

      = =C2=A0

      Let=E2=80= =99s not make people similarly hate GNAP by inventing even more novel terms, when existing terms will fit the bill.=C2=A0 Client wasn= =E2=80=99t a perfect choice but adding =E2=80=9COrchestrator=E2=80=9D to t= he vocabulary menagerie would definitely make things worse.

      = =C2=A0

      =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

      = =C2=A0

      From: TXAuth &l= t;txauth-bounces@ietf.org> On Behalf Of Tom Jones
      Sent: Tuesday, August 11, 2020 8:44 AM
      To: Dave Tonge <dave.tonge@moneyhub.com>
      Cc: Francis Pouatcha <fpo@adorsys.de>; Justin Richer <= ;jricher@mit.edu>; Dick Hardt <d= ick.hardt@gmail.com>; Benjamin Kaduk <kaduk@mi= t.edu>; Fabien Imbault &= lt;fabien.imbault@gmail.com>; Denis <den= is.ietf@free.fr>; txauth@ietf.org
      Subject: Re: [GNAP] Terminology

      =C2=A0

      the term "orchestator" does no= t match any use case i have.

      Let's be clear that there are four entities to a single transaction in the real world sense of things. (and others that support the=C2=A0 transaction.)

      Then we can focus on the end point roles. I will focus on the data privacy issues, API's hav= e the same parties with different terminology.

      1. the subject of the data to be transferred.

      2. the user of a grant from the subject to act as delegate. (see https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the user)

      3. the site that has a repository of user data with legal obligations to protect that data (the GDPR) (role resource server.)

      4 the site that wants either access to the data, or some privacy preserving statement about the existence and content of the data. (role of client, vendor, PISP, etc.)

      5. some sorts of facilitator sites for allowing access (roles like authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been left out of OAUTH for good reason.

      =C2=A0

      This is a note supporting the separation of roles from legal entities.=C2=A0 BTW, I firmly believe that the legal entity also needs to be ID'd by th= e transaction.

      Peace ..tom

      =C2=A0

      =C2=A0

      On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:

      Hi all<= /p>

      =C2=A0<= /p>

      I agree that "client&qu= ot; can be confusing. I would be in support of alternative terminology.

      We can always have some wording that explains that an "Orchestrator"= ; in GNAP plays a similar role to "Client" in OA= uth.

      =C2=A0<= /p>

      Dave

      =C2=A0

      On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <fabien.imbault@gmail.com> wrote:

      Hi Francis,

      =C2=A0

      I like your proposal, seems much more intuitive.=C2=A0

      =C2=A0

      Fabien=C2=A0

      =C2=A0

      Le mar. 11 ao=C3=BBt 2020 = =C3=A0 04:17, Francis Pouatcha <fpo@adorsys.de> a =C3=A9crit=C2=A0:

      Hello Denis, Justin, Dick, Fabien,

      =C2=A0

      In this post (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_Ki= mjOBJqdmQY-JOGNw/) i suggested we use the word "Orchestrato= r" to designate the piece of software that orchestrate interaction between "Requestor" (a.k.a. User), AS and R= S to obtain the protected resource.=C2=A0

      =C2=A0

      We are turning around the same topic. As soon as we go beyond=C2=A0the original oAuth protocol, the word 'Client' becomes confusing.

      =C2=A0

      In the same response, I suggest=C2=A0we talk about "roles" = and not "entities".

      =C2=A0

      Best regards.<= /u>

      /Francis

      =C2=A0

      On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:

      I still think that client was the right name in OAuth 2, as the client wanted to do a client-server interaction, so the client used OAuth 2 to get an access token to interact with the "server".

      =C2=A0=

      I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC.=C2=A0=

      =C2=A0=

      /Dick<= /p>

      =E1=90=A7

      =C2=A0

      On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <jricher@mit.edu> wrote:

      On Aug 6, 2020, at 12:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

      =C2=A0<= u>

      The term client in OAuth came from the computer science definition of client-server interaction.

      =C2=A0<= u>

      This, I would argue, is exactly why it=E2=80=99s = a bad label for something that=E2=80=99s distinctly more specific in this context, and I would love to see GNAP adopt a more specific label for the role that we traditionally called =E2=80=9Cclien= t=E2=80=9D in OAuth.

      =C2=A0<= u>

      =C2=A0=E2=80= =94 Justin



      = =C2=A0

      The client is getting an access token so it can call a server, specifically, a resource server (to differentiate it from the authorization server).

      = =C2=A0

      The confusion in my experience usually stems from people working=C2=A0with software=C2= =A0that is acting in multiple=C2=A0roles. IE, the software=C2=A0that is acting = as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context.<= /p>

      = =C2=A0

      = =C2=A0

      = =C2=A0

      =E1=90=A7=

      =C2= =A0

      On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <fabien.imbault@gmail.co= m> wrote:

      Hi,=C2= =A0

      <= /u>=C2=A0

      To me, client has always been a strange word in the context of OAuth, as it has a meaning well defined both in everyday life (this client is a good customer) and in computer science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any teaching experience shows that it does make the concepts hard to grasp for a majority of (clever) people.

      <= /u>=C2=A0

      As for the RO, previous discussions suggested Resource Controller=C2=A0(RC)=C2= =A0also, which may be a bit more specific than manager.=C2=A0<= /u>

      <= /u>=C2=A0

      Fabi= en=C2=A0

      = =C2=A0

      On Thu, Aug 6, 2020 at 1:00 PM Denis <denis.ietf@free.fr> wrote:

      = Justin and Dick,=

      = =C2=A0

      = [Was:=C2=A0 "Revisiting t= he photo sharing example (a driving use case for the creation of OAuth)"]

      = =C2=A0

      = So let us attempt to define new terms:

      initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)

      = In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:<= u>

      Resource Owner (RO): entity capable of granting access to a protected resource

      = I propose to replace it with Resource Manager (RM):

      Resource Manager (RM) : application or user that manages an access decision function of a Resource Server<= /u>

      Denis

      = =C2=A0

      I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in=C2=A0the past, then that role should have a name not being used already in OAuth or OIDC.

      =C2=A0

      Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified.=C2=A0<= u>

      =C2=A0

      For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "rol= e" and "entity&= quot;.

      =C2=A0

      /Dick

      =E1=90=A7

      = =C2=A0

      On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit.edu> wrote:<= /u>

      I=E2=80=99m in favor of coming up with a new term that=E2=80=99s a better fit, but I=E2=80=99m n= ot really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using =E2=80=9Ccl= ient=E2=80=9D and come up with a new, more specific and accurate term for the role than to define =E2=80=9Cclient= =E2=80=9D as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusi= ng =E2=80=9Cconsumer= =E2=80=9D to =E2=80=9Cclient= =E2=80=9D, but OAuth 2 doesn=E2=80=99t u= se the term =E2=80=9Cconsumer= =E2=80=9D at all, nor does it use =E2=80=9Cserver= =E2=80=9D on its own but instead always qualifies it with =E2=80=9CAuthoriz= ation Server=E2=80=9D a= nd =E2=80=9CResource Server=E2=80=9D.

      =C2=A0

      GNAP can do something similar, in my opinion. But what we can=E2=80= =99t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated =C2=A0b= y OAuth 2 and its terminology. We don=E2=80=99t = have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It=E2=80= =99s going to be a delicate balance!

      =C2=A0

      =C2=A0=E2=80=94 Justin<= /u>



      On Aug 4, 2020, at 3:32 PM, Warren Parad <wparad@rhosys.ch> wrote:=

      =C2=A0

      I think that is fundamentally part of the question:<= u>

      We are clear that we are producing a protocol that is
      conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
      from OAuth 2.0 but with different definitions may lead to unnecessary
      confusion<= u>

      =C2=A0

      If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.=

      =C2=A0

      Food for thought.

      - Warren<= /u>

      Warren Parad

      Founder, CTO=

      Secure your user data and complete you= r authorization architecture. Implement=C2=A0Authress.=

      =C2=A0

      =C2=A0

      On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <kaduk@mit.edu> wrote:=

      Hi Denis,

      On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis wrote:
      > Hi Justin,
      >
      > Since you replied in parallel, I will make a response similar to the one
      > I sent to Dick.
      >
      > > Hi Denis,
      > >
      > > I think there=E2=80= =99s still a problem with the terminology in use here. What
      > > you describe as RS2, which might in fact be an RS unto itself, is a
      > > =E2=80=9CClient= =E2=80=9D in OAuth parlance because it is /a client of RS1/. What you
      > > call a=C2=A0=E2=80=9Cc= lient=E2=80=9D has no analogue in the OAuth world, but it is not at
      > > all the same as an OAuth client. I appreciate your mapping of the
      > > entities below, but it makes it difficult to hold a discussion if we
      > > aren=E2=80=99t us= ing the same terms.
      > >
      > > The good news is that this isn=E2=80=99t OAu= th, and as a new WG we can define
      > > our own terms. The bad news is that this is really hard to do.
      > >
      > > In GNAP, we shouldn=E2=80=99t= just re-use existing terms with new definitions,
      > > but we=E2=80=99ve got= a chance to be more precise with how we define things. >
      > In the ISO context, each document must define its own terminology. The
      > boiler plate for RFCs does not mandate a terminology or definitions section
      > but does not prevent it either. The vocabulary is limited and as long as
      > we clearly define what our terms are meaning, we can re-use a term already > used in another RFC. This is also the ISO approach.

      Just because we can do something does not necessarily mean that it is a
      good idea to do so.=C2=A0 We a= re clear that we are producing a protocol that is
      conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
      from OAuth 2.0 but with different definitions may lead to unnecessary
      confusion.=C2=A0 = If I understand correctly, a similar reasoning prompted Dick to
      use the term "GS" in= XAuth, picking a name that was not already used in
      OAuth 2.0.

      -Ben

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

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

      =C2=A0

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

      =C2=A0

      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/mail= man/listinfo/txauth

      =C2=A0

      --
      TXAuth mailing list
      TXAuth@ietf.org
      https://www.ietf.org/mailman/listinfo/txauth<= /a>


      =C2=A0

      --

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

      =C2=A0

      I would be against using "grant" as both a ver= b and a noun and stick purely with one or the other. (In the charter the on= ly use of "grant" is in the verb: "granted").
      =

      Using i= t as both a verb and a noun will be confusing and less accessible.

      I think it will be confusing to say "The Grant Server is= sues a grant to the Grant Client representing access that has been granted&= quot;

      Whether the access takes place via a token being retur= ned and used at a resource server, or "claims" that are directly = returned from the "Grant Server" I think should be largely irrele= vant when it comes to the naming of the roles.

      In almost all= use cases that I have seen the "Grant Server" is making a policy= based decision "to grant" access to requested resource(s). To me= , that is the fundamental operation happening. I think nearly all use cases= can be applied to that, e.g. the GS grants access to
      =C2=A0- identity= =C2=A0attributes for the end user
      =C2=A0- verify=C2=A0an identity at= tribute (e.g. that user is over 18)
      =C2=A0- all users photos at resour= ce server X
      =C2=A0- a single photo with id 12345 at resource server Y<= /div>
      =C2=A0- resource of type X at any resource server that trusts the Gran= t Server
      =C2=A0- call a payment API with specific properties (e.g. amo= unt < 5)
      =C2=A0- call a file storage API
      =C2=A0- call a "= contract signing" API with specific properties (e.g. contract hash of = xxx,)
      =C2=A0
      While "client" is problematic, it does now= have wide spread usage, so perhaps we are stuck with it.=C2=A0
      Ho= wever I agree with Justin and think "Grant Client" makes things m= ore confusing.

      What is wrong with keeping "Client"= and "Authorization Server"?=C2=A0

      Dave

      <= /div>



      Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales,= company registration number 06909772. Moneyhub Financial Technology Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

      = DISCLAIMER: This email (including any attachments) is subjec= t to copyright, and the information in it is confidential. Use of this emai= l or of any information in it other than by the addressee is unauthorised a= nd unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts are virus-free, it is the recipient's sole responsibility to scan a= ll attachments for viruses. All calls and emails to and from this company m= ay be monitored and recorded for legitimate purposes relating to this compa= ny's business. Any opinions expressed in this email (or in any attachme= nts) are those of the author and do not necessarily represent the opinions = of Moneyhub Financial Technology Limited or of any other group company.


      --0000000000009db96205acc1de21-- From nobody Thu Aug 13 06:47:53 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 09EAE3A0C43 for ; Thu, 13 Aug 2020 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ulaVUltvjDZX for ; Thu, 13 Aug 2020 06:47:49 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AFF3A0C41 for ; Thu, 13 Aug 2020 06:47:48 -0700 (PDT) Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d83 with ME id F1nl230022bcEcA031nl0Q; Thu, 13 Aug 2020 15:47:46 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 13 Aug 2020 15:47:46 +0200 X-ME-IP: 90.79.51.120 To: Dick Hardt Cc: Francis Pouatcha , Justin Richer , Benjamin Kaduk , "txauth@ietf.org" References: <583aedda-ae41-1f3e-6623-671f2197614c@free.fr> <20200804185313.GT92412@kduck.mit.edu> <1b4a6a43-4c57-92b4-f442-2da58a2d0d70@free.fr> From: Denis Message-ID: <6678f154-31e7-2d01-2002-f3600f589c96@free.fr> Date: Thu, 13 Aug 2020 15:47:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BBDB8F157D7C00D5C7B8F900" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth) 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: Thu, 13 Aug 2020 13:47:52 -0000 This is a multi-part message in MIME format. --------------BBDB8F157D7C00D5C7B8F900 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dick, I first jump on the following exchanges: [Dick] Most deployments today accomplish (2) by the developer reading RS documentation. I'm in favor of showing that step in an abstract diagram. [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk. One of the goals is for any Client to access any RS without the need to read any documentation. [Dick]That is impractical. Most RSes today have resource specific APIs. The Client is either reading a standard API doc, or the resource specific API doc. I am not so sure that it is impractical. In 2012, Geert Jansen considered the possibility for complete auto-discovery by the API user, so that the API can be used by a human with a web browser, without any reference to external documentation. See the "Form Definition Language" in :https://restful-api-design.readthedocs.io/en/latest/forms.html In his view, forms need to specify three pieces of information: 1.    How to contact the target and format the input. 2.    A list of all available input fields. 3.    A list of constraints with which the input fields must comply. Hence, in his view, the form consists of 3 parts: form metadata, field definitions, and constraints. What do you think ? The second point on which I would like to insist is about the use of a "dialog box" for user interaction. This wording is used in RFC 6973. In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured. Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS, instead of the AS. This means that we should define a "consent" endpoint at the RS. Denis > comments inline ... > > On Wed, Aug 12, 2020 at 7:14 AM Denis > wrote: > > Hi Dick, > >> Hi Francis, responses inline ... >> >> On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha > > wrote: >> >> Hello Dick, >> >> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt >> > wrote: >> >> Hi Francis >> >> The user is an entity, not a role in the protocol in how >> I am defining roles, so steps (1) and (7) are confusing >> to me on what is happening. >> >> "Requestor" is the role (*was* User). So the UML participant >> refers to the role "Requestor" >> >> >> I still don't understand what is happening in (1) and (7) > > > Would you provide more explanation? > >> >> >> >> I also think that (2) could be an extension to GNAP, >> rather than part of the core protocol. >> >> If you make it an extension, you hide. It shall rather be an >> optional, integral part of the protocol. >> >> >> Most deployments today accomplish (2) by the developer reading RS >> documentation. I'm in favor of showing that step in an abstract >> diagram. > > [Denis] Really by reading RS documentation ? Non capisco > l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk. > > One of the goals is for any Client to access any RS without the > need to read any documentation. > > > That is impractical. Most RSes today have resource specific APIs. The > Client is either reading a standard API doc, or the resource specific > API doc. > >> But it is not clear to me what the requirements for (2), and they >> may vary radically across use cases, so putting it in the core >> document seems to be getting ahead of ourselves. > > [Denis] I can only reinsist on earlier explanations given about > the Client-server use cases built along "Privacy by Design" since > they are fundamental. > > I agree with the principle of "Privacy by Design". There are LOTS of > details in how to do what you outline below, and I expect they will be > radically different across use cases, which is why I don't think it > fits into the core document, but I do agree with calling it out in the > abstract. When I publish an updated draft, let me know what you think > then. > > > Taking into consideration both the "data minimization" > principle and the "user participation" principle when a user > first authenticates to a RS leads to the following: > > 1) When accessing a RS for the first time, the user should be > informed of the authentication means proposed by the RS. The > user should be able to use a dialog box > where some choices are presented by the RS. The user should be > able to locally make his own choices and to indicate his > consent to its Client. > > 2) When a user chooses to perform one operation on a RS, the > RS should limit the data to be collected from the user to only > what is strictly necessary > to perform that operation. That data consists of specific > types of attributes that need to be guaranteed by one or more > ASs. The user should be able > to use a dialog box where some ASs choices are proposed by the > RS. The user should be able to locally make his own choices > and to indicate > his consent to its Client. > > It is important to notice that the choices that will be > proposed to a user may depend upon previous personal > information voluntarily released by that user. > This means that the choices proposed by the RS may be tailored > for the user. Furthermore, the proposed choices may only be > disclosed to already authenticated users. > > Denis > >> In some open banking designs, >> - the "Orchestrator/Negotiator/Client" will not know the AS >> to talk to unless the call (2). >> >> >> Have you put these use cases in the wiki? >> >> - the request (2) might result in an exemption, meaning no >> need for further authorization, allowing to skip (3, 4, 5) >> and even (6). >> >> >> Agreed. >> >> ᐧ > > > ᐧ --------------BBDB8F157D7C00D5C7B8F900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
      Dick,

      I first jump on the following exchanges:
      [Dick] Most deployments today accomplish (2) by the developer reading RS documentation. I'm in favor of showing that step in an abstract diagram.

      [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk.
      One of the goals is for any Client to access any RS without the need to read any documentation.

      [Dick]That is impractical. Most RSes today have resource specific APIs. The Client is either reading a standard API doc, or the resource specific API doc.
      I am not so sure that it is impractical.

      In 2012, Geert Jansen considered the possibility for complete auto-discovery by the API user, so that the API can be used by a human with a web browser,
      without any reference to external documentation. See the "Form Definition Language" in : https://restful-api-design.readthedocs.io/en/latest/forms.html

      In his view, forms need to specify three pieces of information:
      1.    How to contact the target and format the input.
      2.    A list of all available input fields.
      3.    A list of constraints with which the input fields must comply.
      Hence, in his view, the form consists of 3 parts: form metadata, field definitions, and constraints.

      What do you think ?


      The second point on which I would like to insist is about the use of a "dialog box" for user interaction. This wording is used in RFC 6973.

      In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.

      Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS,
      instead of the AS. This means that we should define a "consent" endpoint at the RS.

      Denis


      comments inline ... 

      On Wed, Aug 12, 2020 at 7:14 AM Denis <denis.ietf@free.fr> wrote:
      Hi Dick,

      Hi Francis, responses inline ... 

      On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <fpo@adorsys.de> wrote:
      Hello Dick,

      On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <dick.hardt@gmail.com> wrote:
      Hi Francis

      The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.
      "Requestor" is the role (was User). So the UML participant refers to the role "Requestor"

      I still don't understand what is happening in (1) and (7)

      Would you provide more explanation?
       
       


      I also think that (2) could be an extension to GNAP, rather than part of the core protocol.
      If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol.

      Most deployments today accomplish (2) by the developer reading RS documentation. I'm in favor of showing that step in an abstract diagram.

      [Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk.

      One of the goals is for any Client to access any RS without the need to read any documentation.


      That is impractical. Most RSes today have resource specific APIs. The Client is either reading a standard API doc, or the resource specific API doc.
       
      But it is not clear to me what the requirements for (2), and they may vary radically across use cases, so putting it in the core document seems to be getting ahead of ourselves.

      [Denis] I can only reinsist on earlier explanations given about the Client-server use cases built along "Privacy by Design" since they are fundamental.

      I agree with the principle of "Privacy by Design". There are LOTS of details in how to do what you outline below, and I expect they will be radically different across use cases, which is why I don't think it fits into the core document, but I do agree with calling it out in the abstract. When I publish an updated draft, let me know what you think then.

       


      Taking into consideration both the "data minimization" principle and the "user participation" principle when a user first authenticates to a RS leads to the following:

      1) When accessing a RS for the first time, the user should be informed of the authentication means proposed by the RS. The user should be able to use a dialog box
      where some choices are presented by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client.

      2) When a user chooses to perform one operation on a RS, the RS should limit the data to be collected from the user to only what is strictly necessary
      to perform that operation. That data consists of specific types of attributes that need to be guaranteed by one or more ASs. The user should be able
      to use a dialog box where some ASs choices are proposed by the RS. The user should be able to locally make his own choices and to indicate
      his consent to its Client.

      It is important to notice that the choices that will be proposed to a user may depend upon previous personal information voluntarily released by that user.
      This means that the choices proposed by the RS may be tailored for the user. Furthermore, the proposed choices may only be disclosed to already authenticated users.

      Denis

       
      In some open banking designs, 
      - the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2).

      Have you put these use cases in the wiki?
       
      - the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).

      Agreed.
      ᐧ


      ᐧ


      --------------BBDB8F157D7C00D5C7B8F900-- From nobody Thu Aug 13 06:49:04 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 650CD3A0C43 for ; Thu, 13 Aug 2020 06:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_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 J9O4KMZBTVO4 for ; Thu, 13 Aug 2020 06:49:00 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 AFE6F3A0C46 for ; Thu, 13 Aug 2020 06:49:00 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id s189so7384724iod.2 for ; Thu, 13 Aug 2020 06:49:00 -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=eesK6L2YktfSqaYIhyHEQK4tvYyHJIn9IKt+lUq9Meg=; b=lgZBVvYekRidrFkNGwflDmK0jNigeVqkQWoimjFsbL+HE66x98L5aQDBeOtQ8iTL3T vDiksHxQRoeW5K1bpTj7dZU31OKkWZCawJnXJPQ1hwLlgEfcH9SYMKwpcWl8fuBk/eR0 Heqea8nzDCVVfDL6CSktKexWIQYBwiGi/Y9+d1YelaCEFW4dTNstsO+HB3AACo8HLLUH ppWy8NI9DWSQbN+hrFGsfsViuvxat27i0OJVWWMKQRN6KOVxpY8AjhwmAow3zqYkO/dJ 4gqGMAx1xfgtZx4sYfA0BYggiW27EDJScbYUjF/0ML4z+q12OuwtuioYjlyd0oRtC5EQ 46gg== 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=eesK6L2YktfSqaYIhyHEQK4tvYyHJIn9IKt+lUq9Meg=; b=Uz9n5dg6vvwyVVvVTUa/mKoYmK6ap8xk3LwCHwpW0eTn4a8F5fNKqsxhjJRiehGLnl lVyWAvNP1+ZZluBD0d+EUc7SR2mwPOtCW4bZjqWbMwESYkDszohmKNBB5PUWGBan+xYF mMOJYuHSl4M3DG9NMCixX7zeFNpZxSPydnaQZFwMK0YB9aNYUiZ/ucUP6CqQ02Q7tP8t MO5bG5gBNq0RJF3jW8byn7VjRl8E4XEB7z5Vpis6xJkvXMsQ2M5YWPvYSlAjntFD3L/L vEfqoCKJZIv+4fSpuUuFQMkJsTCV823bYZxyioe7ILwro/Cbvw75LczocjEZk/D1eUwz 17IA== X-Gm-Message-State: AOAM53141hhH3NkvITAVzcYjp5YywDcMIiHlUed374JofXPZ2wPlOhBz zZ2uhi2wmyyjWbysNDgCLzdo0K916PZ58omCw3w= X-Google-Smtp-Source: ABdhPJy6aGMMGjdto08qoc80jG/SlqC1CxRZdAL2WzPPU9uidk6iCx8/KQwJ3SUyvSOhA0YNTDeSkKEbNkeCbSnxGhY= X-Received: by 2002:a6b:e70d:: with SMTP id b13mr4900966ioh.141.1597326539892; Thu, 13 Aug 2020 06:48:59 -0700 (PDT) MIME-Version: 1.0 References: <0DA045F0-1DFC-4CEC-B160-D4440B49B4EB@mit.edu> <79713735-7BD3-4178-BB42-A433370D8EA2@mit.edu> <526A862D-824E-48B3-AB28-7AABFF60A1A9@mit.edu> In-Reply-To: From: Fabien Imbault Date: Thu, 13 Aug 2020 15:48:48 +0200 Message-ID: To: Dave Tonge Cc: Justin Richer , Dick Hardt , Mike Jones , Tom Jones , Francis Pouatcha , Benjamin Kaduk , Denis , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000002d7e05acc29155" Archived-At: Subject: Re: [GNAP] Terminology 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: Thu, 13 Aug 2020 13:49:03 -0000 --000000000000002d7e05acc29155 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Nothing inherently wrong with Client/AS, which has worked for years in the context of OAuth2. The question is to know whether we can build the new protocol with the same concepts and deal with their known limitations, or if we're better off with more adapted concepts less prone to misunderstandings. Verb vs Noun: Problem is that the grant (noun) can only be understood if there is a grant(verb), i.e. some action that grants something. The grant (noun) definition directly derives from the verb : "something granted ..." I personally have no issue even with the fairly convoluted "The Grant Server issues a grant to the Grant Client representing access that has been granted" (except perhaps from the word Client, but that's a different issue). By the way, grant is nothing new, it's used extensively in OAuth2 as "grant types" (whatever that means). Dick summarized well the reasons why he uses GS instead of AS : 1) "grant" is in the working group name (a weaker reason, but still has been approved). Question: would our reasoning if the protocol ended up being called OAuth3? 2) grant =3D larger in scope than AS (not only authorization), as it at lea= st includes idclaims + other use cases like payment (?) - no consensus, see difference in appreciation between Justin and Dick As for "Client", if most people think it is problematic, it seems a good reason to change if we find a better alternative. Quoting Dick again: "The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context." and later "I do agree that it is not the best term in GNAP. Primarily because GNAP is a combination of the client from OAuth 2, and the relying party from OIDC." So far there's no consensus however, recent tries: Initiating Application (Denis), Orchestrator (Francis). Cheers Fabien On Thu, Aug 13, 2020 at 2:59 PM Dave Tonge wrote: > I would be against using "grant" as both a verb and a noun and stick > purely with one or the other. (In the charter the only use of "grant" is = in > the verb: "granted"). > > Using it as both a verb and a noun will be confusing and less accessible. > > I think it will be confusing to say "The Grant Server issues a grant to > the Grant Client representing access that has been granted" > > Whether the access takes place via a token being returned and used at a > resource server, or "claims" that are directly returned from the "Grant > Server" I think should be largely irrelevant when it comes to the naming = of > the roles. > > In almost all use cases that I have seen the "Grant Server" is making a > policy based decision "to grant" access to requested resource(s). To me, > that is the fundamental operation happening. I think nearly all use cases > can be applied to that, e.g. the GS grants access to > - identity attributes for the end user > - verify an identity attribute (e.g. that user is over 18) > - all users photos at resource server X > - a single photo with id 12345 at resource server Y > - resource of type X at any resource server that trusts the Grant Server > - call a payment API with specific properties (e.g. amount < 5) > - call a file storage API > - call a "contract signing" API with specific properties (e.g. contract > hash of xxx,) > > While "client" is problematic, it does now have wide spread usage, so > perhaps we are stuck with it. > However I agree with Justin and think "Grant Client" makes things more > confusing. > > What is wrong with keeping "Client" and "Authorization Server"? > > Dave > > > > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > --000000000000002d7e05acc29155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
      Hi,

      Nothing inherently wrong with Client/AS, which has wor= ked for years in the context of OAuth2. The question is to know whether we = can build the new protocol with the same concepts and deal with their known= limitations, or if we're better off with more adapted concepts less pr= one to misunderstandings.

      Verb vs Nou= n:
      Problem is that the grant (noun) can only be understood if there is= a grant(verb), i.e. some action that grants something.=C2=A0
      The grant= (noun) definition directly derives from the verb : "something granted= ..."

      I personally=C2=A0have no issue even with= the fairly convoluted "The Grant Server issues a grant to the Grant Client repre= senting access that has been granted" (except perhaps from the word Cl= ient, but that's a different issue).
      By the way, grant is nothing= new, it's used extensively in OAuth2 as "grant types" (whate= ver that means).=C2=A0

      Dick summarized well the reasons why he uses GS instead of = AS :=C2=A0
      1) &quo= t;grant" is in the working group name (a weaker reason, but still has = been approved). Question: would our reasoning if the protocol ended up bein= g called OAuth3?
      2= ) grant =3D larger in scope than AS (not only authorization), as it at leas= t includes idclaims=C2=A0+ other use cases like payment (?) - no consensus,= see difference in appreciation between Justin and Dick

      As for "Client", if most people think it= is problematic, it seems a good reason to change if we find a better alter= native.=C2=A0
      Quot= ing Dick again: "The confusion in my experience usually stems f= rom people working=C2=A0with software=C2=A0that is acting in multiple=C2=A0= roles. IE, the software=C2=A0that is acting as a=C2=A0client=C2=A0in once context, is also acting as an RS in other co= ntexts, or even acting as an AS. The other confusion is that people view=C2= =A0clients=C2=A0as being the software the u= ser is using -- although it may not be acting as a=C2=A0client=C2=A0in the oauth context." and later "I do a= gree that it is not the best term in GNAP. Primarily because GNAP is a comb= ination of the=C2=A0client=C2=A0from OAuth = 2, and the relying party from OIDC."

      So far there's no consensus however, recent tries: Initiating Appli= cation (Denis), Orchestrator (Francis).=C2=A0

      Cheers
      Fabien



      On Tue, Aug 11, 2020 at 10:11 PM Mike Jones &= lt;Michael.Jones=3D40micr= osoft.com@dmarc.ietf.org> wrote:

      Thanks for lettin= g me know.=C2=A0 I=E2=80=99ll wait to print the copies I=E2=80=99m going to= review until I see that the new version has been published.=C2=A0 (I alway= s do my best cover-to-cover spec reviews by reading them on paper =E2=80=93 preferably outside in nice weather, away from other distractions.)<= u>

      =C2=A0<= /u>

      =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike

      =C2=A0<= /u>

      From: TXAuth <txauth-bounces@ietf.org> On Beha= lf Of Dick Hardt
      Sent: Tuesday, August 11, 2020 12:54 PM
      To: Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; GNAP Mailing List <txauth@ietf.org>
      Subject: [GNAP] Design team formed

      =C2=A0

      Mike: I'm going to add in the updated terms I ju= st posted to the list to the XAuth ID later today.

      =C2=A0

      On Tue, Aug 11, 2020 at 10:02 AM Dick Hardt <dick.hardt@gmail.com<= /a>> wrote:

      Leif / Yaron: thanks for organizing!

      =C2=A0

      Kathleen, Mike, Fabien: thanks for stepping up.

      =C2=A0

      Mike: I have a number of adjustments I had queued fo= r a new version prior to the WG meeting, but I did not think it was useful = to push new concepts or material given=C2=A0the path to have a design team.= =C2=A0

      =C2=A0

      =C2=A0

      Thanks for your confidence in me and the rest of the= design team.=C2=A0 I plan to read both individual specs cover-to-cover as = part of my preparation for this work.

      Dick and Justin, are there additional edits you plan to publish before I sh= ould do my review, or should I review the currently published drafts?

      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

      -----Original Message-----
      From: TXAuth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
      Sent: Tuesday, August 11, 2020 3:43 AM
      To: GNAP Mailing List <txauth@ietf.org>
      Subject: [GNAP] Design team formed

      Thank you all for attending the inaugural GNAP meeting at IETF-108. We had = quite a few volunteers, and the chairs picked the following people for the = design team:

      * Kathleen Moriarty
      * Justin Richer
      * Dick Hardt
      * Mike Jones
      * Fabien Imbault

      Kathleen has graciously agreed to convene the sessions and report on the te= am's outcome. Thank you all who volunteered!

      We expect the design team to decide on a solution outline that combines the= best of both proposals, and present this outline by Sep. 15. Anything is a= s usual subject to approval by the whole working group.

      Thanks,
      =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leif and Yaron



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

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

      --
      TXAuth mailing list
      TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
      As a concrete exampl= e: a user may want to use an application to access rs_domain/directory1 and= rs_domain/directory2 in read and write, which are managed by a RO.=C2=A0
      What I suggested is that the Client may (optionally) carry out its= consent through a decoupled IS server (separated from the AS), that displa= ys the UI based on the RS requirements =3D> the IS knows what informatio= n is used, but the IS may be chosen by the IS independently from the AS or = even run by the Client itself.=C2=A0
      In this case, suppose the RO= only provided consent for rs_domain/directory1 for read.=C2=A0
      W= e now need to get back to the AS to mint the access token.=C2=A0
      =
      If we want the AS to not know about the RS, we either :=C2= =A0
      - don't supply the rs_domain at all -> the JWT says th= at directory1 in read access is authorized. The downside is that we actuall= y cannot control to which URL the authorization=C2=A0applies. In that case = I agree with your either or statement.=C2=A0=C2=A0
      - or find a wa= y to hide it (not sure if that's practical, hence my questions on RS hi= ding). This would have the benefit of still allowing directed tokens -> = the JWT says that rs_petname/directory1 in read access is authorized.
      =
      =C2=A0
      Either way, the AS has not been provided any informat= ion as to where this token will effectively be used.=C2=A0


      I don't t= hink the abstract flow deals with those privacy concerns.=C2=A0
      =
      To solve the privacy problem addressed in this thread, we= need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have= to issue a VC (Verifiable Credential) to the Student (in his role of RC). = The Student will then present this claim to UNIV-1 during his registration.= In this case we need no Grant negotiation and=C2=A0no AS.

      FI : That may be useful but it's not = enough. What you describe only works because you take a very specific use c= ase, aka registration. This fits well into DID/VC without requiring authori= zation per say. However grant negotiation=C2=A0is still required for more g= eneral settings of authorization.=C2=A0=C2=A0
      I've added a DI= D example to my implementation, will publish it soon.=C2=A0

      <= /div>
      =C2=A0
      Best regards.
      /Fran= cis
      =C2=A0
      Then I agree with you on the audience field of th= e token, if left empty it simplifies part of the problem, although it remov= es a big part of the control you may want from directed tokens. That's = why I'm willing to better develop the RS hiding idea.=C2=A0

      Fabien=C2=A0

      Le mar. 11 ao=C3= =BBt 2020 =C3=A0 05:58, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>= ; a =C3=A9crit=C2=A0:
      Hello=C2=A0Denis,

      what you descri= be in the use case seems to be the default behavior of the protocol. Let me= map it with this abstract protocol flow:

      +-----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ = =C2=A0+-----------+ =C2=A0+----+ =C2=A0+---------------------+
      | Request= or |=C2=A0 =C2=A0 =C2=A0 | Orchestrator | =C2=A0|=C2=A0RS=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0| GS | =C2=A0| Resource Controller |
      | is UNIV-1 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 is UNIV-1= =C2=A0 =C2=A0|=C2=A0 |=C2=A0is UNIV-0 |=C2=A0 |=C2=A0or |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0is=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =
      |=C2=A0 =C2=A0Staff=C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 | Registr. App |=C2=A0 | Server=C2=A0 =C2=A0 |=C2=A0 |=C2=A0AS |= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0Student=C2=A0 =C2=A0 =C2=A0 =C2=A0|
      += -----------+=C2=A0 =C2=A0 =C2=A0 +--------------+ =C2=A0+-----------+ =C2= =A0+----+ =C2=A0+---------------------+
      =C2=A0 |(1) RegisterStudent=C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
      =C2=A0 |---------------------->|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|(2) RequestRecordIntent(RecordType,StudentId,
      <= font face=3D"monospace">=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorI= d):AuthRequest[RecordType,StudentId]
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=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) AuthZRequest(RecordType,Stud= entId,OrchestratorId)
      =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|--------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =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) Con= sentRequest(RecordType,
      =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0OrchestratorId):Cons= ent
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<-------------->|
      =C2=A0 |=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=A0AuthZ[= RecordType,StudentId,OrchestratorId]
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<--------------= -------------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|(2) RequestRecord(RecordType,StudentId,OrchestratorId)
      =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0:Reco= rdOf[StudentId]=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
      =C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<-------------->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |(7) Register= ed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
      =C2=A0 |<----------------= ------|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
      =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +

      we assume t= he authz request sent by "Client" to "AS" describes the= protected resource without referring=C2=A0to the authz server. An AS can i= ssue the authz to release the graduation record=C2=A0 of a student ((5)=C2= =A0AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to th= e target university.=C2=A0

      What matters for this authz object= is:
      - StudentId: a reference to = the student as known to the resource server.
      - RecordType: a reference to a resource of type graduation reco= rd as understandable=C2=A0 by the resource server.
      -=C2=A0OrchestratorId: reference to the Orchestrator. Can= be used to bind authz to Orchestrator.

      But:
      - RS must trust AS issued token.
      -=C2=A0StudentId must be known to RS, AS and=C2= =A0Orchestrator.

      Therefore, the AS does not need to know the = RS. Keep the audience field empty.

      Same principle applies for= the second use case.

      =
      What privacy problem do you see here?

      Best regards.
      /Fra= ncis

      On Tue, Aug 4, 2020 at 5:08 AM Denis <denis.ietf@free.f= r> wrote:
      =20 =20 =20

      I tried my best twice to download three use cases in the Use cases directory, but I failed.

      Rather than failing a third time, here is the direct link of the second try:

      https://g= ithub.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-seve= ral-ASs-built-along-%22Privacy-by-Design%22-(PbD)

      Denis







      --
      Txauth mailing list
      Txa= uth@ietf.org
      https://www.ietf.org/mailman/listinfo/txauth<= /a>


      --
      --
      TXAuth mailing list
      TXA= uth@ietf.org
      https://www.ietf.org/mailman/listinfo/txauth<= /a>


      --